Service Restoration Verification Rate

A technician resets a service, and the monitoring dashboard goes green. Is the service actually usable for the affected customers?

Service restoration verification rate measures the share of claimed restoration cases with evidence that the agreed service checks passed before closure. Define the case and the restoration.

An incident, customer outage or field-service repair can have different verification steps, so use a declared population, and remember that a technical fix is not the same as normal service performance for the user. Atlassian's incident handbook describes resolution as the affected service resuming its usual function, and ServiceNow's incident process includes confirming restoration before closure, but these are service-management examples, not universal contract rules.

Set the checklist and match the impact. Check service availability, critical transaction, error level and affected geography where relevant, because a test from one healthy site may not verify a region that actually failed.

Check dependency paths too, since the core system can be up while payment, login or customer notifications remain broken, and use monitoring evidence knowing that telemetry can support restoration but may miss user-facing failures not covered by probes. Use customer checks selectively, because a customer confirmation may be needed under contract or severity policy, and the absence of a reply is not automatically proof of failure or success.

Record separate timestamps for fix applied, tests run, normal performance observed and case closed. Define the numerator as cases with the required verification evidence passing under the applicable checklist, and the denominator as cases marked restored during the report window, not unrelated new incidents.

Treat partial service honestly, since one restored feature cannot close the whole outage if the remaining impact is material under the definition, and use a hold period for unstable incidents so that a defined monitoring interval can catch recurrence before closure. Keep evidence traceable by saving test IDs, dashboard views, logs or field checks, not just a checkbox marked verified, and protect personal data by using approved retention and access.

If a check cannot run, document the reason and alternate evidence rather than pretending it passed, and watch auto-close rules, because a ticket that closes on a timer may not have passed restoration verification. Handle repeats and failures with care.

A new failure after a genuine verified recovery may be a new case, but a failed initial check should reopen the same case, and when a required probe fails the restoration claim stays provisional with the failing evidence preserved, so a later successful retest shows its own time and result rather than overwriting the first finding. Segment by severity, separate speed from verification because mean time to restore tells how quickly service came back while the verification rate tells whether restoration claims were supported, audit sample cases for checks run against a test environment instead of production, tie ownership across the incident lead, service owner and customer-facing team, and use the result to improve recovery quality without delaying honest incident updates to affected people.