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. A comment by the issue's own reporter does not count, and neither does a comment or a status move by an app or a service-desk customer; the section on who counts says why.

How these charts work

Two bar charts over the same projects, sorted ascending by average response time so the fastest project reads first. The first chart carries the p50 (median) alone: what a normal issue experiences. The second carries the p90: what the slowest tenth experiences. One series is drawn on each, so nothing on either axis competes with the figure the chart is named for.

They are separate charts on purpose. The p90 runs several times the p50 on most projects, so on one axis the median bar loses most of its height. 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 p90 is days behaves differently from one that is uniformly slow, and the two raise different questions.

Why the average is not drawn

The view computes an average per project and Deep Analysis still receives it, but the typical chart plots the median alone. First-response times are long-tailed, so a project's mean is set by the slow responses the tail chart already shows rather than by the level a normal issue experiences; it is not a second reading of the typical case at all. Measured across one portfolio on 2026-08-27, every project's mean ran between thirty and seventy-five times its median, so drawn on one linear axis the mean set the height and the median it was there to be compared against lay flat on the floor. The figure left the axis, not the panel: hover a bar and the tooltip gives that project's average in minutes, to one decimal. The average is also still the sort key for the axis, so the order the projects appear in is set by a figure the chart does not draw.

Why the 99th percentile is not drawn

The view still computes a p99, but the page does not plot it and Deep Analysis leaves it out. A 99th percentile over first-response times has a ceiling set by how long the project has been recorded: the slowest one percent are the issues nobody has answered yet, and their measured wait grows with the length of the record rather than with anything the team did. Measured across one portfolio on two dates eleven days apart, every project's p99 moved with the age of the record. Drawn beside the p90 it also set the axis, leaving the series it was meant to be compared against flat on the floor. A figure that moves with the calendar is not a tail worth asking a reader to interpret, so the p90 is the tail this page draws.

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 on both charts and the project keeps its place on each axis, labeled with the number of responses behind it, so a withheld value is visibly different from a fast one. No average is offered for such a project either, and for the same reason: a mean over one or two responses is not a level anyone can compare against a project measured hundreds of times. Its tooltip says how many responses were measured and gives no figure at all. 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; such a bar is drawn with a "0 min" label, so a measurement of zero reads on the axis as a value rather than as a gap.

Who counts as a responder

A comment by the issue's reporter does not count as a response: the reporter is the person asking, so their own comment, usually added detail, says nothing about when anyone answered. The reporter is the one recorded when the issue was created (the creator, where no reporter was recorded), and an erased reporter matches nobody. A status move by the reporter still counts, because it moves the issue on.

Responses by accounts Jira reports as apps, such as Automation for Jira, or as service-desk customers do not count on either arm: neither their comments nor their status moves are taken as the first response. Each project on the panel shows how many of its issues received such a response; a project the 25% coverage floor removes leaves the panel with that count, so its excluded responses are not shown anywhere. Responses by accounts Jira returned no type for, by erased accounts and by events with no recorded actor still count, because any of them may be a person, and each project on the panel shows how many of its responses came from each.

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. Responses by app accounts are left out separately, as described above. A rule that acts under a person's account, or under an account Jira returned no type for, still counts, because Jira records its action as that account's: a project where such a rule comments on every new issue immediately will report a median near zero minutes, and the number is accurate for what it measures. 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.