An incident response game day is the cheapest reliability investment most engineering teams still refuse to make. The 2026 Catchpoint SRE Report, based on 418 responses from reliability professionals worldwide, names it as one of five defining trends: resilience has to be practiced. Teams that deliberately test failure report more confidence and better preparedness. And yet the same report finds production chaos engineering is still far from standard practice. Most organisations value resilience testing in principle and almost never schedule it.

That gap matters more in 2026 than it did five years ago, because the incidents that hurt now are rarely the ones nobody saw coming. They are the ones where detection worked fine and coordination did not. August alone gave the industry several examples. GitHub's August 17 incident ran 7 hours and 47 minutes, and the published account describes a capacity component that failed to scale at a new traffic peak, followed by client retry behaviour that made recovery harder rather than easier. Cloudflare's status page logged more than a dozen separate incidents in the first half of the month across R2, Durable Objects, Workers KV and regional networking. In none of these cases was the problem that monitoring stayed silent. The problem was how long it took to get the right people, with the right context and the right authority, into the same conversation.

That is a rehearsable skill. This post is about how to rehearse it without needing a chaos engineering platform, a dedicated resilience team, or permission to break production.

What the 2026 SRE Report actually says about practiced resilience

It is worth separating the report's findings from the marketing gloss that usually surrounds them. The 2026 Catchpoint SRE Report surveyed reliability professionals across a range of roles, company sizes and industries, and its five headline trends are: speed is the new trust, AI is reducing some toil but not all of it, resilience has to be practiced, integration shapes AI's value, and learning is a reliability issue.

Three of those five are really the same finding viewed from different angles. Reliability work is increasingly bottlenecked on human capability rather than on tooling. Teams have more telemetry than they can use, more alerting surface than they can tune, and less protected time than they need to get good at any of it.

Toil is down for some teams and unchanged for others

Roughly half of respondents say AI adoption has reduced toil. The interesting half is the other one. For a large share of practitioners, AI assistance has either made no measurable difference or shifted the work rather than removing it. Median toil sits around a third of engineering time. If you are on a team where the AI-assisted triage story has not landed yet, you are not behind, you are in the majority of the distribution.

This has a direct bearing on game days. Automation reduces the volume of routine work. It does not reduce the difficulty of the non-routine work, and non-routine work is exactly what an on-call engineer faces at 2am during a novel failure. Practice targets the part of the job automation is worst at.

Testing failure builds confidence that reading runbooks does not

The report's framing here is careful and worth repeating: teams that deliberately test failure build more confidence and preparedness. Confidence is not a soft outcome. An on-call engineer who hesitates for six minutes because they are not sure whether they are allowed to fail over, or whether the secondary responder is reachable, has added six minutes to every incident of that class for as long as the hesitation persists. Rehearsal removes hesitation in a way that documentation does not, because documentation is read in calm conditions and incidents do not happen in calm conditions.

Why chaos engineering stalled and game days did not

Chaos engineering has had roughly a decade of enthusiastic conference talks and comparatively modest adoption. The reason is not that the idea is wrong. It is that the version of the idea most teams encountered was expensive.

The objection is blast radius, and it is a fair one

Running fault injection against production requires a maturity floor most teams have not reached: reliable rollback, tight blast radius controls, a clear abort procedure, and enough organisational trust that nobody's promotion is at risk if the experiment goes badly. Teams that lack any one of those correctly decline to inject failure into production. The mistake is concluding that resilience testing is therefore off the table.

The cheaper version nobody runs

A game day does not require breaking anything. At its simplest it is a scheduled exercise in which a facilitator introduces a realistic scenario, the on-call rotation responds using the tools and channels they would really use, and the team debriefs afterwards. You can run a valuable one against a staging environment. You can run a valuable one with no environment at all, purely as a tabletop exercise, and still discover that your escalation policy points at a person who left the company in March.

The insight is that your systems and your response process are two separate systems, and only one of them requires production access to test. The response process is the one that fails more often and gets tested less.

Your on-call path is the untested system

Every engineering organisation has an implicit response pipeline: signal fires, someone is notified, that someone acknowledges, context is gathered, scope is assessed, additional people are pulled in, a decision is made, the decision is executed, customers are informed, and the whole thing is written up. Most teams have tested exactly one link in that chain, which is the first one, and they tested it accidentally by having real incidents.

The five things that break in the human path

Notification delivery. The alert routed correctly but the responder's phone was on Do Not Disturb, the push notification was silently dropped, or the notification went to a channel nobody has open at 3am. This is the single most common silent failure, and it is trivially testable.
Escalation timing. The escalation policy says fifteen minutes to secondary. Nobody has verified that the secondary is actually paged at minute fifteen, or that the secondary for the current rotation is the person the schedule claims. Overrides, holidays and recent team changes quietly break this constantly.
Authority ambiguity. The responder knows what to do and is not sure they are allowed to do it. Can they roll back a deploy owned by another team? Can they fail over the database at 4am without a director on the call? If this is undefined, it gets resolved during the incident, expensively.
Context assembly. The responder needs the recent deploy list, the dashboard, the runbook and the last similar incident. If those live in four systems with four different logins, the first fifteen minutes of every incident are spent on retrieval rather than diagnosis.
Communication forking. Technical work happens in one channel, stakeholder updates happen in another, and the person doing the technical work becomes the person answering questions. Response quality collapses at exactly the moment it matters.

What August's outages showed about coordination

The retry amplification pattern from the GitHub incident is instructive beyond its technical detail. A component hit a capacity limit, degraded, and then client retry behaviour turned a degradation into something closer to a sustained outage. Recovery required not just fixing the component but understanding that the recovery attempt itself was contributing to load.

That is a very hard thing to reason about under pressure, and it is a very easy thing to rehearse. A tabletop scenario that says "the primary API is returning 503 for 30 percent of requests and error rates keep climbing even after you scale the fleet" forces exactly the conversation you want people to have had before it counts. Teams that have discussed retry storms once will recognise the second one in minutes rather than hours.

How to run your first incident response game day

Aim for sixty to ninety minutes, quarterly at minimum, monthly if you can sustain it. Anything longer becomes an event that gets postponed. The goal of the first one is not realism, it is establishing that the exercise happens at all.

Step 1: pick a scenario that has already happened to somebody

Do not invent an exotic failure. Take a real public incident from the last quarter and localise it to your architecture. A third-party provider degrading, a certificate expiring, a config change with an unintended global scope, a database failover that took longer than expected, a dependency returning slow rather than failing. Public postmortems are a free scenario library, and the plausibility matters because engineers disengage from scenarios they consider unrealistic.

Step 2: decide what is real and what is simulated

Be explicit about this before you start and write it on the invite. A useful default for a first game day is that the alerting path is real, the paging is real, the channel is real, and everything downstream of "responder opens a dashboard" is narrated by the facilitator. This tests the parts that break most often while requiring no environment changes. Later game days can move the boundary further toward reality.

Step 3: write the injects, not the answers

An inject is a piece of information the facilitator releases at a specific time. Write six to ten of them in advance. For example: at minute zero, error rate alert fires. At minute four, a second alert for a downstream service. At minute nine, a message from support saying two enterprise customers have reported failures. At minute eighteen, the obvious mitigation does not work. At minute twenty five, someone asks whether to post to the status page.

Do not write down what the team should do. The point is to observe what they actually do. A facilitator who is steering toward a predetermined answer learns nothing about the team's real behaviour.

Step 4: run it in the channel you actually use

This matters more than it sounds. If your real incidents run in Slack, run the game day in Slack, in a real incident channel, with the real bot commands. A game day held in a conference room with a slide deck tests recall. A game day held in the working environment tests the workflow, and the workflow is what has bugs in it. Label the channel clearly as an exercise, and put "THIS IS A DRILL" at the top of every inject so nobody escalates it to a real customer conversation.

Step 5: time the things that matter

Have someone record timestamps for: first alert, first human acknowledgement, first message in the incident channel, incident commander identified, scope understood, first mitigation attempted, first stakeholder communication sent. These seven timestamps produce a far more actionable picture than a single mean time to resolution figure, because they tell you which link in the chain is slow.

Most teams discover their slowest link is between "first acknowledgement" and "scope understood". That interval is almost entirely context assembly, and it is very responsive to tooling improvements.

Step 6: debrief like a postmortem, because it is one

Run the debrief the same way you would run a real incident review, with the same blameless framing described in the Google SRE book's postmortem culture chapter. Ask what surprised people, where they hesitated, what they could not find, and what they were unsure they were allowed to do. Produce action items with owners and dates. A game day with no action items either was not hard enough or was not debriefed honestly.

A sixty minute game day script you can copy

Here is a concrete structure that works for a first run with a team of five to eight people:

Minutes 0 to 5, setup. Facilitator states the rules, confirms what is real and what is simulated, names the timekeeper, and reminds everyone this is blameless and not an evaluation of individuals.
Minutes 5 to 10, cold start. Trigger the real alert. Say nothing. Watch how long acknowledgement takes and where the first message lands. Resist the urge to help.
Minutes 10 to 35, the scenario. Release injects on schedule. Add one complication that invalidates the first hypothesis. Add one stakeholder pressure inject, such as a simulated message from a customer success lead asking for an ETA.
Minutes 35 to 40, the curveball. Remove a resource. The obvious owner is unreachable, or the primary dashboard is unavailable, or the runbook turns out to be for the previous architecture. This is where you learn the most.
Minutes 40 to 45, wind down. Facilitator declares the scenario resolved and states the ground truth of what was happening.
Minutes 45 to 60, debrief. Walk the timeline. Collect friction points. Assign three to five action items with owners.

Run this four times a year and you will have retired a meaningful amount of hidden risk, at a cost of roughly six engineering hours per quarter.

Metrics worth tracking across game days

Single game days are anecdotes. Sequences of game days are data. Track a small number of things consistently:

Time to acknowledgement. Alert fired to a human confirming they have it. If this exceeds your escalation threshold during a drill, it exceeds it in production too.
Time to commander. How long until one person is clearly coordinating. Teams that never name a commander tend to have several people independently investigating the same hypothesis.
Time to first stakeholder update. Often the worst number in the set, because it is nobody's explicit job.
Number of tool switches. Count how many distinct systems responders opened. This is a direct proxy for context assembly cost and the easiest thing to improve.
Action item completion rate. The percentage of game day action items closed before the next game day. Below fifty percent means the exercise is theatre.

Common ways game days go wrong

A few failure modes show up reliably enough to warn about in advance.

Scheduling it during business hours only

Business hours drills test the best case: everyone is awake, at a desk, and already in context. That is not when incidents hurt. You do not need to wake people at 3am, but running one drill a year at an awkward hour, with consent and compensation, reveals things that daytime drills never will.

Letting senior engineers rescue the exercise

If the principal engineer who knows the system best jumps in at minute three, you have learned that the principal engineer is good, which you knew. Rotate the responder role deliberately toward newer team members and have the senior people observe silently. The discomfort is the value.

Treating it as a performance review

The moment a game day feels like an evaluation, people optimise for looking competent rather than for surfacing problems. Nothing useful is learned after that point. Say explicitly and repeatedly that the exercise is testing the system and the process, not the individuals.

Never changing anything afterwards

The most common outcome is a good drill, an honest debrief, a list of action items, and no follow through. Assign each action item an owner and a date in the same tracker you use for real incident follow ups, and review them at the start of the next game day. If your incident tooling can create action items directly from the channel where the drill happened, the completion rate goes up substantially, simply because the friction of transcription disappears.

Where Slack-native on-call tooling makes rehearsal cheaper

The practical barrier to running game days is rarely philosophical. It is that setting one up takes an afternoon, and the afternoon never appears. Anything that reduces setup cost increases the number of drills that actually happen.

This is the argument for keeping the on-call workflow in the place where the team already works. If the schedule, the paging, the incident channel, the escalation and the action items all live in Slack, a game day is a channel and a scenario document rather than a project. A facilitator can check who is really on call, page them for real, watch the escalation fire at the configured interval, and capture follow ups without anyone leaving the conversation. Pagerly is built for that model: rotations, overrides, escalation policies and incident channels operate inside Slack, so the environment you rehearse in is identical to the environment you respond in.

The general principle holds regardless of tooling choice. Rehearse in the real channel with the real routing. A drill run somewhere other than your production response path validates a process you do not have.

Start with one drill this quarter

The 2026 SRE Report's finding is not that teams disagree with resilience testing. It is that they agree with it and do not do it, which is a scheduling problem rather than a belief problem. Scheduling problems respond to lowering the bar.

So lower it. Pick a public postmortem from the last quarter, spend thirty minutes writing eight injects, book sixty minutes with your on-call rotation, and run it in your real incident channel with real paging. You do not need production fault injection, a resilience team, or executive sponsorship to do that.

Test the human path first. Notification delivery, escalation timing and authority ambiguity fail more often than infrastructure does, and cost nothing to test.
Run drills in your real tooling. A tabletop in a meeting room tests memory. A drill in your incident channel tests the workflow.
Instrument the intervals, not just the total. Seven timestamps tell you which link is slow. One duration tells you nothing actionable.
Make the action items real. Owners, dates, and a review at the start of the next drill, or the exercise decays into theatre within two cycles.
Protect the blameless framing aggressively. The first time a drill feels like an evaluation is the last time anyone surfaces a real problem in one.

The teams that handled August's incidents well were not the ones with better monitoring. Detection was fine almost everywhere. They were the teams for whom the coordination was routine, and coordination becomes routine exactly one way, which is by having done it before it mattered.