Most digital health teams can tell you what their uptime target is. Far fewer can say, with evidence, how well they behave in the first hour of a failure. IncidentOps, the informal name for organised handling of unplanned service disruptions, is where that gap lives. This article offers an audit checklist: twelve questions you can answer from your own records, grouped by theme, with a note on what a healthy answer looks like and why. It concerns information systems and administration only, and it contains no clinical guidance of any kind.
A word on sources. The framing follows the Ops Atlas write-up of IncidentOps, which describes the label as a loose stand-in for incident management and collects practices from several published playbooks. Where we quote a number, it comes from that write-up and we say so; where it is a judgement call, we flag it as ours.
How to run this audit
Pick the last three disruptions your team handled, large or small. Pull whatever exists: chat transcripts, ticket timestamps, the notes someone typed afterwards. Score each question as yes, partly or no for each event, then look at patterns rather than single results. Memory flatters, records do not, so when nobody can produce evidence, count the answer as a no. You are not chasing a grade here, only a shortlist of repairs.
Section A: Declaration and severity
- Were the criteria for declaring written before the event? A healthy answer points to a document. As an illustration the Atlas lists Google’s triggers: a second team has to be involved, customers notice the effect, or an hour has passed without a solution. Whatever your triggers are, they should not depend on someone’s mood.
- How long passed between first symptom and declaration? Look at the timestamps. Long gaps usually signal a culture where declaring feels like admitting fault. The Atlas argues the opposite approach: punishing counts of declared incidents only teaches people to stay quiet.
- Was severity assigned from a shared scale? Check whether two people would classify the same event the same way. If not, the scale is too vague.
Section B: Roles and command
- Did someone act as commander without also being the main fixer? The evidence is in the transcript: did the coordinator spend the incident issuing instructions, or typing commands? The Atlas treats the commander as an explicit non-resolver.
- Was it clear who was allowed to change systems? Count how many people made changes. If the number is large and nobody can list them, you have an access discipline gap.
- Was there a deputy or a documented handover? For events that lasted past a shift change, check whether the handover was spoken and acknowledged, as the Atlas recommends, or merely assumed.
Section C: Communication
- Did updates appear on a promised rhythm? The Atlas suggests an opening post within roughly five minutes of the call starting and refreshes no more than twenty minutes apart across the first two hours. Compare your timestamps against a rhythm like that.
- Did the status channel survive the failure? Ask whether your status note and paging route depend on the systems they describe. The Atlas highlights a 2017 cloud storage incident where the provider’s service-health console was unusable until late morning for exactly this reason, and it advises that these channels must not share fate with what they report.
Section D: Review and learning
- Was a review owner named before the call finished? Dragging your feet at this step is how reviews quietly never take place, so the check is worth doing on every event.
- Do actions carry one owner and one date? Vague actions and equally ranked actions fall into the Atlas’s list of anti-patterns, along with actions that are mostly mitigations rather than preventions.
- What fraction of actions closed on time? The Atlas proposes this as a headline measure, with one published example setting a four- or eight-week target depending on the service.
- Did the review stop at “human error”? If the root cause line names a person, keep digging. The Atlas, quoting classic safety research, notes that hindsight distorts how we judge decisions made in the moment.
Reading the evidence on metrics
Most audits also ask about recovery time, and here the research urges caution. The Atlas draws on a study of incident durations, which are skewed: a few very long events dominate the average. The simulations it cites took a true ten percent shortening of durations and found that the mean-time figure failed to register as a gain in three company datasets, at rates of 38, 40 and 20 percent. Run the other way, with nothing changed, there was a 19 percent chance of an apparent half-hour improvement. Its author, as the Atlas relays, would rather teams distrust such averages from the outset whenever a trend is at stake.
The practical suggestion is to report the full distribution of detection, acknowledgement, mitigation and recovery times, alongside the minutes of error budget consumed, the pager load averaged over the trailing 21 days, and the action closure rate. Always state which phase and which population a figure refers to, since the same abbreviation can mean repair, recovery, respond or resolve.
Reading the human side
An audit that ignores people misses the largest source of risk. Look at your on-call rota: the Atlas offers a worked case in which six engineers covering two weekly slots around the clock carry about a third of the load each, above Google’s 25 percent cap, and it estimates that roughly eight people would be needed. Also glance at the wider landscape. The Atlas also mentions a 2026 vendor survey answered by 1,363 volunteers: 30 percent of them cited alert fatigue, and 16 percent found coordination across teams painful. People who opt in are not a random sample, so treat the figures as conversation starters, not yardsticks.
A caution about secrets in tooling
If you manage paging configuration as code, check one more thing. The Atlas notes that marking a value as sensitive in an infrastructure-as-code plan only hides it from the printed plan output; the stored state and certain outputs can still reveal routing keys. Use encrypted remote state and restrict who can read it. This is a quiet issue that audits often miss.
What good evidence looks like
It helps to agree up front what counts as proof. A screenshot of the status note with its timestamp is proof that an update went out. A chat export is proof of who gave instructions. A calendar entry created during the call is proof that a review owner was named. A line in your tracker with an owner and a date is proof that an action exists. Verbal assurances, however sincere, are not proof, and auditors should say so politely. If a record is missing for an event, that is itself a finding: it tells you the team has no habit of writing things down while they happen, and a scribe role is the cheapest remedy.
Try to audit with someone who was not part of the incident. A fresh reader notices ambiguity that the participants have unconsciously filled in from memory, and the exercise doubles as practice for the facilitator role in later reviews.
Turning results into a plan
Count your noes and partlys, and group them. Most teams discover that the weak spots cluster in one section, often communication or review. Pick the two cheapest fixes. Typical first moves are a written declaration policy and a template for updates, then a named review owner on every serious event. Schedule a re-audit in a quarter and compare.
If you want a gentle reminder that careful follow-up matters in other settings too, the site’s overview of how functional class is used to describe a person’s day-to-day limits shows how a simple shared scale supports clear conversation, and the article on grading what a clinician hears through the stethoscope does the same for another standard vocabulary. They are general educational reading and not connected to systems operations.
Summary
An IncidentOps audit does not need new tools: a few past events, a spreadsheet and an honest hour. The twelve questions above test declaration, command, communication and learning, and the metric notes keep you from trusting a single misleading average. Run it, fix the cheapest gaps, and repeat next quarter with the same questions so that the trend is real rather than imagined.
