By Amit Shingala, Co-Founder and CEO, Motadata
Ask most IT operations teams how quickly they respond to incidents and they will show you a detection figure. Mean time to detect has been the focus of a decade of tooling investment, and it shows. Monitoring platforms now spot deviation in seconds across estates that would have been opaque ten years ago.
Mean time to resolve has not improved at anything like the same rate. That divergence is worth sitting with, because it points at a segment of the incident lifecycle that almost nobody instruments.
Consider what actually happens after an alert fires. Someone reads it and decides whether it matters. They work out which service is affected, then which team owns that service, then whether that team is the right one to act at this hour on this day. Only then does a ticket exist. The distance between the alert and the assigned ticket is covered by integration rules, scripts written by whoever was on call when the last outage happened, and a considerable amount of individual judgement.
That path is rarely designed. It is almost never measured.
The Half of the Incident Nobody Watches
Both ends of an incident are well instrumented. The monitoring platform records when a threshold was breached and when the alert was raised. The service desk records when the ticket was created, when it was assigned, when work started and when it closed. Reporting is built from those two sets of timestamps.
The segment between them produces almost no data. Nothing records how long the alert sat before a human looked at it, how many times it was reassigned before reaching a team that could act, or how often the first assignment was wrong. When an organisation reports mean time to resolve, that measurement typically begins at ticket creation, which means the handoff is not slow in the reporting. It is invisible in the reporting.
Figure 1. Both ends of the incident lifecycle generate timestamps. The segment between them does not.
This is why detection improvements can be genuine and still fail to show up in resolution figures. A platform that shortens detection from four minutes to forty seconds has improved a segment that was already fast, while the segment that was already slow remains untouched and unobserved.
Ownership Is the Hard Part
The technical work of creating a ticket from an alert is not difficult. Every monitoring platform can post to a service desk API, and most organisations have that wired up. The difficulty is deciding what the ticket should say and who should receive it.
In a hybrid estate, a single symptom rarely maps to a single owner. Elevated latency on a customer-facing service could originate in the application, the network path, the cloud platform, the database, or a dependency two hops away that nobody has documented. The alert describes the symptom accurately. It says nothing about cause, and ownership follows cause.
Figure 2. A single symptom in a hybrid estate maps to several plausible owners.
What resolves that ambiguity in most organisations is a person who has been there long enough to know how the estate fits together. That knowledge works, and it does not scale. It leaves with the individual, it degrades as the estate changes around it, and it is unavailable at three in the morning when the person holding it is asleep.
The alternative is to hold service relationships and ownership as data rather than as institutional memory. That means a configuration management database that reflects current dependencies rather than the state of the estate at the last audit, and ownership records maintained as a first-class asset rather than a spreadsheet updated after reorganisations.
Both are unglamorous, and neither demos well. They are the difference between automation that routes correctly and automation that routes confidently to the wrong queue.
Designing the Handoff
Treating the path from alert to ticket as architecture rather than plumbing changes three things in practice.
The first is enrichment at creation. A ticket that arrives carrying the affected service, its upstream and downstream dependencies, recent change records against those components, and the current owner is a different object from a ticket carrying a threshold breach and a hostname. The receiving engineer spends their first ten minutes acting rather than establishing context.
The second is correlation before creation. A single underlying fault often produces alerts across several monitored components at once. Without correlation, each becomes its own ticket, and several teams begin investigating the same event separately. Correlating related signals into one incident before a ticket exists is the difference between one team working a problem and four teams discovering each other halfway through.
The third is measurement of the handoff itself. If an organisation cannot report how long alerts wait before assignment, or what proportion of automated assignments are subsequently rerouted, it cannot tell whether its automation is helping. Reassignment rate is a particularly honest metric, because it is difficult to argue with. Every reroute is an assignment the system got wrong.
Measure Time to Correct Owner
The metric I would put in front of a board is not time to detect. It is time to correct owner, measured from the moment the signal appears to the moment it reaches a team that can act on it without passing it on again.
That number is uncomfortable to produce, which is part of its value. Producing it requires an organisation to admit how much of its incident response depends on individuals rather than systems. It also tends to be the number with the most room in it, because it covers the part of the lifecycle that a decade of detection investment has left alone.
At Motadata we built our observability and service management products to share a data layer for this reason, having watched enough organisations run excellent monitoring into a service desk that could not tell them who owned the thing that had broken. The specific implementation matters less than the sequencing. Get service relationships and ownership into a state you trust, then automate the routing. Teams that do it in the other order tend to spend the following year explaining why their automation programme has not moved the numbers they promised it would.
