Our customers watch us work. The numbers below are what they see.
Every alert and incident Zumidian handles is tracked in PagerDuty, and every customer has full access to the data for their environment. We see the same dashboards our customers see; there's no private scoreboard and no separate version of events. This page explains exactly what each published number means, how it's measured, and what it doesn't claim.
Four rules govern every metric we publish.
One shared source of truth.
Everything is tracked in PagerDuty, and customers have full access to their data. What we publish is what our customers can already see, first hand, in the same system.
The full chain, including the slow number.
We publish time to acknowledge, time to resolve, and time to verified recovery. The last one is hours, not minutes, and we publish it anyway, because verifying recovery against real player-facing signals takes time and pretending otherwise would be marketing.
Means, not cherry-picks.
Incident times skew right: a handful of long incidents pull the average up, never down. Publishing the mean across every alert is the harsher choice, and that's the one we make.
Time-boxed claims.
Every metric carries its measurement window. Numbers without a period attached are marketing. Numbers with one are evidence.
One denominator, by design.
The same 226,378 figure appears under all three metrics, and that's deliberate. Zumidian doesn't run severity tiers or routing queues, so every alert follows the same path: acknowledged, resolved, verified. There's no separate population of alerts that get the full treatment while the rest sit in a queue. One pipeline, one denominator.
1m 48s
MTTA: mean time to acknowledge
The clock starts when an alert fires. It stops when a Zumidian engineer has acknowledged the alert and begun qualification, meaning a human is actively assessing severity and player impact, not an auto-acknowledgement or a bot response.
Published figure
1 minute 48 seconds, mean, across 226,378 alerts between 1 January 2024 and 31 May 2026, spanning 21 customer environments.
Scope: Every alert of every severity, excluding only Zumidian's internal system alerts. We don't get to pick which alerts count.
9m 57s
MTTR: mean time to resolve
The clock starts when the alert fires. It stops when the resolving action is being applied: the incident has been qualified, the runbook is executed, and the fix is in motion. This is the number that answers the operational question of how quickly a problem is being actively fixed.
Published figure
9 minutes 57 seconds, mean, across all 226,378 alerts between 1 January 2024 and 31 May 2026, spanning 21 customer environments.
What's excluded and why: Incidents whose resolution sat outside our approved access boundaries, for example a fix requiring the customer's own engineering change, are tracked separately, as are Zumidian's internal system alerts. We measure what we're accountable for, and we say so.
2h 21m
MTTVR: mean time to verified recovery
Resolution and verified recovery are different claims, so we publish them separately. MTTVR stops the clock only when the fix has passed post-fix validation and recovery is confirmed against real player-facing signals over an observation window. Restoring a server isn't verified recovery. A player being able to log in, matchmake and transact, sustained, is.
Published figure
2 hours 21 minutes, mean, across all 226,378 alerts between 1 January 2024 and 31 May 2026, spanning 21 customer environments.
Read this number correctly: It does not mean players wait hours for service. The resolving fix is typically in motion within ten minutes; MTTVR includes the observation window needed to confirm, against live player signals, that the recovery held. Most providers don't measure this step at all. We'd rather publish the honest, slower number than stop the clock early.
Exclusions: Exclusions are the same as MTTR.
Transparency
Aggregated across customers, transparent within each.
The published metrics aggregate alert and incident data across 21 customer environments. Our customer agreements don't allow us to attribute specific figures to specific customers, and we wouldn't want a model that depends on naming names.
Within each engagement, the customer sees the same PagerDuty data we do, scoped to their own environment, and can verify every data point first hand. Prospective customers can request reference conversations during evaluation, and references can speak to these numbers from direct experience of the same system.
Scope
What these numbers don't claim.
They don't claim every incident resolves in under 10 minutes. They're means over a defined window, and complex incidents take longer.
They don't claim verified recovery is instant. Confirming recovery against player-facing signals takes an observation window, and the MTTVR figure includes it in full.
They don't cover environments we don't operate in. The figures reflect engagements where Zumidian provides the 24x7x365 operating layer described on this site.
If a number on this page ever stops being true, we'll update it. A metric that can't survive contact with reality isn't worth publishing.
FAQ
Common questions about these metrics.
How does Zumidian measure MTTR?
From the moment an alert fires to the resolving action being applied: incident qualified, runbook executed, fix in motion. The published figure is a mean across all 226,378 alerts handled between 1 January 2024 and 31 May 2026. Verified recovery is measured separately as MTTVR, with the clock stopping only after post-fix validation against player-facing signals.
Where does Zumidian's incident data come from?
Every alert and incident is tracked in PagerDuty. Customers have full access to the data for their environment, so Zumidian and each customer see the same view of the same records. There's no separate internal version of the numbers, and each customer sees only their own data.
Why is MTTVR so much longer than MTTR?
Because they measure different things. MTTR stops when the fix is being applied, typically within minutes. MTTVR stops only when recovery has been validated against real player-facing signals over an observation window. The gap between them is the cost of actually verifying recovery instead of declaring it.
Can these numbers be verified?
Yes, within each engagement. Every customer can audit the underlying data first hand in the shared system, and prospective customers can request reference conversations during evaluation.
See what Zumidian engineers do in your environment →See how your current numbers compare.
A Game Operations Review looks at your coverage, incident flow, response times and launch readiness against the operating model behind these metrics.