NOC Performance: 4 metrics before the incident even starts.

Most NOC performance advice rides along with the incident process and its metrics. What is missed is the work before the incident, especially the work that never becomes one. That gap means detection, one of the NOC's most critical functions, goes untracked, and it leaves both performance and root cause open to speculation.

Alert metrics, the missing four

These are the alert metrics, the measures of the work before an incident exists, named here the way Signal9 reports them. They outline a team's strengths and weaknesses instead of averaging everyone into an incident number.

• Time to Detect. From arrival to first human touch. This shows how quickly the team is able to react and evaluate any incoming alert, real or not.
• Insights: Disruption patterns here can expose distractions, overload, or individual performance issues.
• Time to Decide. From arrival to the real-or-not call, the moment the alert is cleared, becomes an incident, or pages someone. Judgment speed is the NOC's craft, and no standard framework has a name for it.
• Insights: Sliced by service or component, it shows where training or documentation is thin.
• Time to Incident. From arrival to a tracked incident, the whole span before the incident record exists, counted only for the alerts that become one.
• Insights: This is the one you can already approximate today, because the incident looks back at the alert that started it.
• Alert-to-incident ratio. What arrived versus what became an incident.
• Insights: This is the workload nobody sees, and the number that finally shows what the room absorbs on a bad week.

Why the hidden number reads slower

One of these can look wrong on the page. Time to Decide sometimes reads slower than Time to Incident, which seems impossible until you see that the two count different populations. Time to Incident is computed on the alerts that became incidents. Time to Decide is computed on every alert the room made a call on, the ones that turned out to be nothing included.

That gap is the whole argument in one place. The alerts that became incidents were the ones that got attention, and a handful of them is a small and flattering sample. If you only track incident metrics, you are seeing that fraction and nothing else. The work that never became an incident is where the real capacity of the room shows up, and it is the half nobody has been able to see.

Two ways the standard metrics miss

• It starts too late. MTTR, as most shops run it, starts when an incident is opened. The noticing, sifting, correlating, and judging that produced the incident all happened before that timestamp. Your NOC can get twice as fast at the part it does alone and the dashboard will not move.
• It only counts the survivors. The six alerts that became incidents get measured. The four hundred the NOC sifted, suppressed, or caught early never enter any metric anywhere. The NOC's largest work product is an invisible denominator.

Root cause runs into the same gap

Take the good case. A monitor fires, the alert becomes an incident, and there is a record of how it was handled. Alert time, who opened the incident, incident time. That satisfies the RCA and gives you a timeline. But when handling breaks down, an alert missed, an escalation that came late, that record cannot isolate where the failure actually happened, because everything around the failure is missing.

• How many other alerts were in flight at the time?
• How did this operator perform on the last 20 or 200 alerts?
• Does this alert have high signal quality, or a history of noise?
• Were any changes made to the alert or its monitor recently?
• How many other operators were actively working alerts?
• Where does this alert land? A shared channel, an inbox, a portal?

A name and a timestamp is not an answer

"Joe took 22 minutes to open an incident" is not enough to identify an area of improvement. Maybe Joe was carrying forty alerts mid-storm. Maybe this alert has cried wolf nine times this month. Maybe it landed in a portal nobody had open. There is no other span in an incident's history where a blind spot like this would be tolerated. Around alert handling, it has always been the norm.

Why you have never seen these numbers

Every measure above, and every question on that list, needs the alert layer to be a system of record, a timestamp for arrival, for eyes, for the decision, for the handoff, kept per signal. In most shops the alert layer is a pile of inboxes and channels, so the data to compute them does not exist. This work is not measured because nobody cares. It is unmeasured because everything upstream from the incident has traditionally been hard to capture.

What it takes to get them

• In house. This is shaped differently in every shop, so there is no single answer. You start by centralizing and normalizing the alerts, then track and report every action taken on them.
• Off the shelf. Signal9 started at exactly this blind spot, and SigOps is the tool that came out of it. Setup is an email forwarding rule or a webhook, pointing the alerts at a shared team board.

Signal9

Signal9 built SigOps this way, the board is the system of record for alerts, every arrival, every decision, every handoff captured as the room works, and Triage Health reads the alert metrics straight off it, Time to Detect, Time to Decide and Time to Incident, with MTTR alongside in its correct place. The context lives there too, what else was in flight, how a signal usually behaves, what changed recently, so the next RCA starts from a record instead of a recollection. The work that never becomes an incident finally earns credit, because for the first time it is countable.

Originally published at signal9.app on August 25, 2026.