Why a baseline, and why these 7
Without a baseline, every improvement is an opinion. These 7 numbers cover detection, resolution, volume, learning, change quality, effort and escalation, and most of them come out of an ITSM export in an afternoon. Use the last 6 to 12 months, and write down every definition so next quarter’s numbers are comparable.
- Time to detect, P50 and P95
- Time to resolve, P50 and P95
- P1 and P2 incidents per month
- Repeat incidents
- Change failure rate
- Tools and engineer-minutes per investigation
- Tier-1 resolution share
| Number | Definition | Where it comes from |
|---|---|---|
| Time to detect (P50, P95) | Minutes from impact start to detection (the first alert or the first ticket, whichever came first) | Incident records, plus the impact start from monitoring history or the postmortem |
| Time to resolve (P50, P95) | Minutes from impact start to service restored, not to ticket closure | Incident records: the restored or resolved time |
| P1 and P2 incidents per month | Network-attributed incidents of each priority, divided by the months in the period | Incident records filtered by priority and by resolving group or configuration item |
| Repeat incidents | Incidents whose cause matches an incident in the previous 90 days, as a count and as a share | Incident records linked to problem records or a cause field |
| Change failure rate | Implemented changes that caused an incident, were rolled back or needed remediation, divided by all implemented changes | Change records and the incidents linked to them |
| Tools and engineer-minutes per investigation | Consoles opened, and total engineer-minutes to an evidence-backed cause, per P1 or P2 | Time logs, or a reconstruction with the engineers |
| Tier-1 resolution share | Network incidents resolved by tier 1 without escalation, divided by all network incidents | Incident records: resolving group and reassignment history |
Field names differ by ITSM product and by customization; map them once and write the mapping down.
Define the clocks before you count
Most arguments about a baseline are about clocks, not numbers. Decide these moments and write them down:
- Impact start: when users or services were first affected. Tickets rarely record it; take it from monitoring history or the postmortem, and add a field for it going forward.
- Detected: the first alert or the first ticket, whichever came first.
- Acknowledged: when a person started working on it. Useful for on-call analysis; not one of the 7.
- Restored: when service was back for users, even through a workaround.
- Closed: when the ticket was closed, often hours or days after restoration while someone waited for confirmation. Do not use it as the resolve time.
In ServiceNow (opens in a new tab), the incident’s opened_at and resolved_at fields are the usual starting points; in Jira (opens in a new tab), Created and Resolved. Check what your teams actually do with them: if an incident is marked resolved when the user confirms rather than when service returns, your time to resolve includes waiting time.
1. Time to detect (P50 and P95)
Definition: detected minus impact start, in minutes, for network P1 and P2 incidents. See MTTD.
How to pull it: export P1 and P2 incidents for the period with their opened time and, where recorded, the impact start. Fill missing impact starts from monitoring history or the postmortem timeline. Where you cannot establish one, leave that incident out of this number and report how many you left out.
Watch for: incidents detected by users. If the first signal was a user call, that call is your detection time, and the gap to the impact start is exactly what this number exists to expose.
2. Time to resolve (P50 and P95)
Definition: restored minus impact start, in minutes, for network P1 and P2 incidents. Where the impact start is missing, use the detected time and say so. See MTTR.
How to pull it: the same export, with the restored or resolved time. Report P50 (the median) and P95, with the number of incidents behind them.
Watch for: tickets resolved long after restoration; reopened tickets (use the final restoration); and incidents whose priority changed midway (count by the highest priority reached or by the final one, and stick to the rule).
3. P1 and P2 incidents per month
Definition: network-attributed P1 incidents per month and P2 incidents per month, counted separately. See P1 / P2.
How to pull it: filter incidents by priority and by the group that resolved them or the configuration item class, then divide by the number of months in the period. Write down which rule makes an incident network-attributed: resolving group, configuration item or cause category.
Watch for: duplicates and child tickets of one major incident (count the parent), and incidents handled on a bridge that never got a ticket (find them in postmortems and chat, and add them).
4. Repeat incidents
Definition: P1 and P2 incidents whose cause matches an incident in the previous 90 days, as a count and as a share of the incidents with a recorded cause. See repeat incident.
How to pull it: each incident needs a cause key: a linked problem record, or a cause category plus the device or circuit. Sort by cause and date, and flag every incident with an earlier match inside 90 days.
Watch for: incidents with no recorded cause. Report their share next to the repeat rate. A high share of unknown causes means the repeat rate is understated, and that share is itself the restored, not fixed number.
5. Change failure rate
Definition: implemented network changes that caused an incident, were rolled back or needed remediation, divided by all implemented network changes in the period.
How to pull it: export the change records with their close code or outcome, and the incidents linked to them (in ServiceNow (opens in a new tab), the incident’s Caused by Change field). Count a change as failed if any of the three conditions holds. Leave canceled and blocked changes out of both the numerator and the denominator, and report them separately.
Watch for: changes closed as successful because nobody complained. If your changes carry a verdict (Verified, Degraded, Rolled back, Inconclusive or Blocked), report the share of implemented changes that were never verified next to the failure rate.
6. Tools and engineer-minutes per investigation
Definition: for each P1 or P2 investigation, the number of separate tools or consoles used, and the total engineer-minutes from the first engineer action to a written, evidence-backed cause. Report the median of each, and the P95 of engineer-minutes. See tools per investigation.
How to pull it: tickets rarely hold this. Take the last 10 to 20 P1 and P2 incidents and reconstruct them with the engineers who worked them: who joined, when, for how long, and which tools they opened. Mark each number as logged, reconstructed or estimated.
Watch for: counting one engineer’s time for a bridge that had six people on it. Engineer-minutes add up across people.
7. Tier-1 resolution share
Definition: network incidents of all priorities resolved by tier 1 without escalation, divided by all network incidents in the period. See tier-1 resolution.
How to pull it: use the resolving group and the reassignment history. In ServiceNow (opens in a new tab), the incident’s reassignment count is a quick first filter: no reassignments and a tier-1 resolving group count as tier-1 resolution.
Watch for: tier 1 closing tickets that were resolved elsewhere, and escalations made by phone that never show in the ticket.
Pitfalls: averages hide the tail
Report P50 and P95, not the mean. Ten incidents resolved in 30, 30, 30, 30, 30, 30, 30, 30, 30 and 600 minutes have a mean of 87 minutes, which describes none of them. The P50 is 30 minutes: the typical case. The P95, calculated the way a spreadsheet’s PERCENTILE.INC function does it, is about 344 minutes: the tail that users and executives remember.
- Small samples. With 20 or fewer incidents, that P95 falls between your two worst cases. Report it with the count, and treat it as a description, not a trend.
- Clock definitions that change. Change a definition and every earlier number must be recomputed, or the trend means nothing.
- SLA clocks. Business-hours clocks and paused SLA timers are for contracts. Use wall-clock time for the baseline.
- Mixed priorities. A P1 and a P4 in one median tell you little. Report P1 and P2 separately where the counts allow it.
- Numbers used on people. Once a number ranks engineers, tickets start being written to move it. Use the baseline to find where the system is slow.
Keep it current
- Recompute every quarter with the same definitions, and keep the definitions next to the numbers.
- Set targets only after two cycles, when you know the normal variation.
- Share the numbers with their definitions attached. A P95 without its clock definition will be misread.
- Add the missing fields to your ITSM (impact start, a cause key, a verdict on changes) so next quarter needs less reconstruction.