First Response Time(2.7.11)

Time from issue creation to first response, summarized per project. A response is whichever comes first: a comment on the issue, or the issue's first transition out of the status family Jira classifies as opening. Both arms are read from the event record, so a response counts whether it came from the assignee, the reporter, or anyone else with access.

How these charts work

Two grouped bar charts over the same projects, sorted ascending by average response time so the fastest project reads first. The first chart carries the average and the p50 (median): what a normal issue experiences. The second carries the p90 and the p99: what the slowest tenth and the slowest hundredth experience.

They are separate charts on purpose. Across measured portfolios the p99 commonly runs hundreds of times the p50, so drawn on one axis the median bar occupies a fraction of a percent of the plot height and reads as zero. Splitting them keeps both readable at their own scale. Compare within a chart, and read across the two for the shape: a project whose median is minutes and whose p99 is days behaves differently from one that is uniformly slow, and the two raise different questions.

When a value is withheld, and when a project is not listed

A project needs enough measured responses before a percentile describes anything. With fewer than 10 measured responses the percentile bars are left empty and the project keeps its place on the axis, labeled with the number of responses behind it, so a withheld value is visibly different from a fast one. The average is left empty too, for the same reason: a mean is drawn as one bar beside every other project's mean, and a mean over one or two responses is not a level anyone can compare against a project measured hundreds of times. The response count and the number of issues created are still shown, so it stays visible how much evidence sits behind the project and why the values were held back.

A project whose measured responses cover less than 25% of the issues it created is not listed at all. That is a separate check from the count, and it exists for a different reason: a project with hundreds of responses spread across thousands of created issues has a large enough sample and still describes only a corner of its own work. A project where nothing was ever answered falls under the same check, and is absent rather than shown at zero.

An empty bar and a bar at zero are different statements. Empty means not measured. Zero means measured, and the interval was shorter than the recording interval.

What is counted, and what is not

Only issues whose creation is in the retained event history appear, so an issue created before the connector was installed is absent rather than shown as slow. Issues that have received no comment and no transition out of the opening status count toward the share of work covered, and contribute no response.

A candidate response recorded at or before the creation event is discarded, because an interval of zero or less cannot describe a response. The two candidates are checked separately, so an issue whose transition carries an unusable timestamp is still measured on its comment, and the other way round; an issue is only left out when neither candidate is usable.

That check removes impossible timings. It does not identify automated ones, and it is not intended to. A project where a rule comments on every new issue immediately will report a median near zero minutes, and the number is accurate: it is measuring the rule, not a person. Where a project's median sits at or near zero, check whether an automation rule is answering first before reading the figure as responsiveness.

This view is pre-aggregated across the whole retained window, so the date filter does not apply to it.

Use Deep Analysis for a read on which projects carry the widest gap between typical and tail response.