by Brent Chapman | May 26, 2026 | Uncategorized
Most companies that invest in improving their incident management see something counterintuitive in the first few months: their incident count goes up. And someone in the leadership chain, looking at the dashboard, asks with concern: “Why are things getting worse?”
The good news is, they’re probably not. What you’re really seeing is evidence that your incident culture is getting better and stronger.
Incident count doesn’t measure system health; it measures how willing people are to declare an incident. When you invest in your incident management program by giving people better training, tools, and processes for handling incidents, they put those things to work, and more situations get treated as incidents. Problems that used to be handled informally (a “spicy bug” that someone handled without declaring an incident, a degradation that the on-call engineer white-knuckled through without telling anyone) now enter your incident process. The company is getting visibility into problems that used to go unnoticed, and using incident management practices and tools to address problems it would have struggled with before.
And it’s a self-reinforcing cycle; the more people use these skills and tools, the more comfortable they get with them, and the more they’re inclined to use them. That’s a good thing, as the way to build the skills and confidence to handle big incidents is by handling lots of little ones; the small incidents are an invaluable training ground.
In most companies, you’re dealing with increases in multiple dimensions simultaneously: number of users, number of products, number of features in those products, usage of those features, number of engineers, level of training and experience of those engineers, and many more. With all those factors increasing, why would you expect incident count to decrease? In a very real sense, rising incident counts can be a sign of success, not failure.
The question to ask isn’t “why are we having more incidents?”, it’s “why aren’t we?” And from there, other good questions follow: are we handling our incidents well, do we have the tools and training that we need, are we learning everything we can from every incident, are we preventing future incidents, are we better prepared to handle those we can’t prevent?
But what happens if leadership decides that rising incident count is a problem and sets a target to bring it down? People get the message: fewer incidents is better. So marginal incidents stop getting declared. The “spicy bugs” go back to being handled quietly. The degradations get white-knuckled through again. The number on the dashboard goes down, but the company has lost both the visibility its incident process was providing and the benefits of handling those situations with proper coordination, communication, and prioritization. The problems didn’t go away; you just stopped applying your best tools to them.
The Goodhart’s Law problem
This pattern has a name: Goodhart’s Law. When a metric becomes a target, it ceases to be a good metric. And it’s not just an incident count problem; it recurs across every incident metric companies reach for.
The logic is straightforward. You focus on a particular metric because you think it captures something you care about. You set a target for the metric because you want to improve. And then smart, well-intentioned people find ways to hit the target. Some of those ways involve actually improving the thing you care about. But some involve optimizing the number without improving the underlying reality, and over time, the second category tends to dominate.
Make incident count a target for reduction, and marginal incidents stop getting declared. Make MTTR a target, and people close incidents prematurely. Make action item completion rate a target, and people write easy action items instead of hard ones. In every case, the metric looks better while the thing you actually care about (learning, reliability, preparedness) stays the same or gets worse.
This is human nature. Smart people optimize for what gets measured; that’s how incentives work. You’re not going to prevent it by writing sternly worded memos about gaming the system. You can only manage it by choosing metrics carefully and then paying attention to the behaviors driven by your focus on those particular metrics. Adjust when those behaviors aren’t what you intended, and be willing to retire the metric when it’s doing more harm than good.
MTTR: the metric everybody loves and nobody should trust
Mean Time to Recovery is the most misleading incident metric in the industry. Leadership loves it because it’s a single number that appears to capture “how fast we fix things.” But it’s deeply flawed, both mathematically and in the incentives it creates.
Incident durations follow a power-law distribution: most incidents resolve quickly, while a small number take much longer. When you average power-law data, you get a number that describes nobody’s actual experience. Let’s imagine that last month you had ten incidents, nine of which resolved in about ten minutes each, and one that took six hours. That gives you an MTTR of 45 minutes, but that’s nowhere close to what any of those incidents actually took; it’s way off of both ten minutes and six hours.
Google SRE ล tฤpรกn Davidoviฤ, in Incident Metrics in SRE: Critically Evaluating MTTR and Friends (O’Reilly, 2023), used Monte Carlo simulations to demonstrate that even with a substantial dataset, MTTR can’t reliably tell you whether your incident response is actually improving. The math doesn’t just give you a misleading number; it can’t even detect real improvement when it’s happening.
There’s also a flattening problem: MTTR treats all incidents as interchangeable, as if the only thing that matters about an incident is how long it took. A six-hour incident where page load times were degraded but the service was still usable somehow scores worse than a one-hour total outage.
The incentive problems are even worse than the mathematical ones. MTTR incentivizes speed over understanding. Thorough incident response sometimes means deliberately slowing down: carefully analyzing symptoms, verifying that a fix actually works, understanding the contributing factors well enough to prevent recurrence. MTTR punishes all of that. A team that’s genuinely improving (catching issues earlier, preventing cascades, tackling more complex problems) can see its MTTR stay flat or even go up. The metric undermines morale and leadership confidence even as the team does better work.
What fire departments get right about metrics
Here’s a lesson that most software companies could learn from fire departments.
Well-managed fire departments decompose their response timeline into segments and set targets only on the segments they can actually control, and expect to be fairly consistent across their incidents. Dispatch time (how long from answering the 911 call to notifying the fire crew) gets a target. Turnout time (how long from notification to crews leaving the station) gets a target. Drive time (from the crews leaving the station to arrival at the incident scene) gets a target. These are process steps that are largely consistent from one call to the next, and if they’re too slow, you can do something about it: hire more dispatchers, change how crews stage at the firehouse, build more stations.
What fire departments don’t set targets for is how long it takes to put out the fire. That depends on the fire. A dumpster fire and a fully involved warehouse fire are different problems with different durations, and no fixed target could meaningfully apply to both.
How long it takes to set up an incident channel, how long it takes responders to acknowledge pages, how long it takes the responders to join the channel and get started: these are your equivalent to the fire department’s dispatch chain. They’re largely consistent from one incident to the next, and you can set targets for them. If you’re not meeting the targets, there are obvious adjustments you can make: auto-create incident channels, set and enforce clearer on-call expectations, and so forth.
On the other hand, the time to find the contributing factors, the time to implement a durable fix, and the total time for the incident: those depend on the details of the particular incident. A misconfigured feature flag and a cascading database failure are different problems. Track trends, investigate outliers, learn from reviews. But don’t set targets. Targets on metrics you can’t control produce gaming, demoralization, or both.
Start with questions, not metrics
The most useful thing is to stop asking “what should we measure?” and start asking “what questions are we trying to answer?”
Are incidents being handled well? Are we learning from them? Is the incident management program serving the business? Is our on-call workload sustainable? Each of these questions leads you to seek different evidence, some quantitative, some qualitative, and the answers are more useful than any single number on a dashboard.
These aren’t easy questions to answer, but they’re better than an easy number that misleads you (like MTTR).
Your dashboards should make you curious, not confident. When you see a trend, the right response isn’t “we know what’s happening.” It’s “we should dig in and find out why.”
And if your incident count went up this quarter? Before you panic, ask why. You might find that your increased focus on incident management is doing exactly what it’s supposed to do.
This is one of the topics I cover in depth in my upcoming book, Incident Management for DevOps and SRE. If you’d like to hear when it’s available, you can sign up at im4ds.com.
If your company needs help with incident management right now, my consulting practice is GreatCircle.com/im.
by Brent Chapman | May 18, 2026 | Uncategorized
Your team burned 40 minutes in an incident chasing a ghost in the metrics. It turned out someone unaware of the incident had picked a bad time for a routine restart.
This is sometimes called “freelancing,” or “going rogue.” It’s working on (or near) the incident without being part of the organized response, and it’s one of the most common complaints I hear from engineering leaders when they talk about incident management: “Our people go off and do their own thing instead of coordinating.”
And they’re right to be concerned. Uncoordinated work during an incident is genuinely costly. Incident “freelancers” muddy the trail. Their queries bog down log systems, making other responders’ searches slower. Their investigations generate artifacts that get mistaken for symptoms of the actual problem. They make changes that mask the issue or introduce new ones. In the scenario above, the incident responders lost 40 minutes because someone’s routine restart looked, in the dashboards, like a clue.
The instinct is to treat this as a behavior problem: tell people not to freelance, put it in the incident guidelines, remind everyone in training. And if they keep doing it, escalate.
Unfortunately, in my experience, most of what gets called “freelancing” isn’t actually freelancing.
What real freelancing looks like
Real freelancing is a deliberate choice: someone knows an incident is underway, knows there’s an organized response, but decides to work the problem independently anyway. Maybe they think they’ll be faster on their own. Maybe they don’t trust the incident commander to use them effectively. Maybe they’ve had frustrating experiences in past incidents and decided it wasn’t worth the trouble.
This is a real phenomenon, and it’s worth taking seriously. When someone with relevant expertise actively avoids the coordinated response, that’s a signal about your incident management culture: something about the experience of participating is broken enough that a skilled person would rather work alone.
Fortunately, this kind of deliberate freelancing is rare. Most companies that think they have a freelancing problem actually have something quite different.
The three gaps
Go back to the ghost in the metrics caused by the routine but uncoordinated restart. The person who did the restart wasn’t working the incident independently; they weren’t working the incident at all. But why were they doing a routine restart in the middle of a Sev-1?
Maybe they had no idea an incident had been declared. Maybe they knew something was going on but didn’t think it involved their systems. Or maybe they suspected it might be a bad time, but had no way to check. Same outcome, three very different backstories, and the fix is different for each one.
When you look at the incidents where uncoordinated work caused problems, most of them trace back to one of these three structural gaps.
The visibility gap. The person didn’t know an incident had been declared. Maybe the declaration went to a channel they aren’t in, or one they haven’t caught up on yet. Maybe the alerting didn’t reach their team. Maybe they were heads-down in focused work and missed it entirely. They weren’t choosing to work outside the response; rather, they didn’t know there was a response to join.
This is the most common gap, and it’s the one that produces the most collateral damage, because the person has no reason to think their normal work might interfere with anything. They restart a service, run a migration, deploy a config change, all routine, all uncoordinated with the incident responders, and all potentially confusing to responders trying to interpret what they’re seeing in the dashboards.
The identity gap. The person is aware something is going on but doesn’t see themselves as relevant. “That’s a payments incident; I’m on the search team.” They carry on with their normal work, not realizing that both teams depend on the same cache cluster and that the real problem is there. The incident responders don’t know to warn them, because they don’t see the shared dependency either.
This gap is subtler than the visibility gap. The information about the incident reached the person; the connection to their own work didn’t.
The mechanism gap. The person knows about the incident and suspects their work might be relevant, but there’s no clear way to check. There’s no place to ask “is now a bad time for routine changes?”, no lightweight way to raise a hand and coordinate. So they make a judgment call, usually in the direction of “it’s probably fine,” and carry on.
This is the gap that frustrates well-intentioned people the most. They would have coordinated if there had been a well-understood way to do so. But the response didn’t have one, so they did the best they could with the information they had.
The plumbing fix
Unlike “real” (i.e., intentional) freelancing, all three of these gaps are plumbing problems, not people problems. They’re about whether your incident response infrastructure makes it easy for people across the company to know an incident is happening, to understand whether their work might be affected, and to coordinate without joining the full response.
What would that look like? In the everyday world, the flashing lights at an emergency scene are a broadcast signal to everyone in the vicinity. They tell passing drivers, pedestrians, and nearby work crews: something is happening here, adjust your behavior. Nobody expects individual firefighters to personally flag down every car that might drive through the scene. The lights do that job passively, at scale, without coordination.
The flashing lights can also serve responders. At an incident scene (in the US, at least), a green flashing light marks the command post, where the incident commander can be found, and arriving responders know to go there to check in for an assignment.
Most companies don’t have the equivalent of flashing lights for their incidents. The incident declaration establishes the incident channel, and the paged responders join it, while everyone else in the company carries on unaware.
The fixes are concrete and mostly unglamorous, and include:
Broad incident visibility. When an incident is declared, the notification should reach beyond the directly-paged responders. A company-wide incidents channel, automated cross-posts to team channels for affected services, a banner in internal tools: whatever fits your company’s communication patterns. The goal is that anyone doing work that might intersect with the incident has a reasonable chance of knowing about it. For significant incidents, that notification can include a simple “hold non-urgent changes, or check with the incident channel” signal.
Dependency-aware notifications. When an incident is declared for one service, teams that own connected services often don’t realize the incident might involve them. If your company maintains a service dependency map (even a rough one), use it: automatically notify teams whose services are upstream or downstream of the affected system. “Heads up: there’s an active incident involving the payments service, which depends on your cache layer” turns “not my problem” into “maybe I should hold off on that restart.”
A lightweight coordination path. Not everyone who might be affected needs to join the incident response. But they need a way to check in: “I was about to restart the cache fleet; is that going to cause problems for you?” A cultural norm that it’s OK (even expected) to ask in the incident channel turns invisible collisions into two-minute conversations.
These aren’t expensive changes. They’re the kind of infrastructure that, once built, quietly prevents dozens of 40-minute detours a year. They work because they address the actual problem: most people who end up doing uncoordinated work during incidents aren’t choosing to go rogue. They just didn’t have the information or the path to coordinate.
Real freelancing, the deliberate kind, still deserves attention. But if you’re seeing a pattern of uncoordinated work during your incidents, start with the plumbing before you start with the lectures.
I’m writing a book about incident management for software engineering companies. If you’d like to hear about it when it’s available, sign up at im4ds.com. And if your company needs help with incident management right now, my consulting practice is GreatCircle.com/im.
by Brent Chapman | May 12, 2026 | Uncategorized
Most companies hold a single post-incident review (PIR) meeting for each incident. They schedule an hour, invite the responders and a handful of observers, walk through the timeline, discuss what went wrong, generate a list of action items, and move on. It feels productive. The calendar invite says “PIR Meeting,” and the meeting does PIR-meeting things.
The purpose of a post-incident review is to learn. Not to assign blame. Not to generate action items. Not to produce a document for the compliance folder. Documentation and action items are side effects of the review process, but they aren’t the point. The point is learning, both individual and organizational, so that you have a better understanding of how your systems actually work and you’re better prepared for the next incident. Because there will be a next incident.
But what most companies call “the PIR meeting” is really three distinct functions crammed into a single calendar invite (or, as I’m fond of describing it, “three meetings in a trench coat”):
A working meeting where the people who responded to the incident sit down together and reconcile their understanding of what happened. They fill gaps in the timeline, surface things they knew but didn’t write down, and pressure-test the contributing factors.
An action items meeting where problems that the incident surfaced are named. The goal should be to identify what needs attention, not to propose solutions; the people best positioned to design fixes may not even be in the room.
A presentation where the findings and lessons are shared with a broader audience beyond the people who lived the incident. This is the meeting’s contribution to organizational learning: spreading what was learned to people who weren’t in the room.
Each of these three functions has a different optimal participant list, a different facilitator posture, a different conversational mode, and a different relationship to time pressure. The working meeting is a small group, collaborative and sometimes messy, exploring what happened without a fixed agenda. The action items meeting shifts into problem-identification mode: what did this incident reveal that needs attention? The presentation is structured and scripted, aimed at an audience that wasn’t in the room for the incident.
If you treated them as three separate meetings, you’d probably invite three different (though overlapping) sets of people to them. Which means that in a single combined meeting, either you haven’t invited everyone who should be there for each function, or some of the people you invited are sitting through parts of the meeting that they don’t need to.
Also, the three functions aren’t equally important: the working discussion is the foundation that the other two depend on. When they’re collapsed into a single session, the results are predictable.
What happens when the three functions compete
When these three functions share a single meeting, the action items tend to dominate, because “what are we going to do about this?” feels like a more urgent conversation than “what can we learn from this?” Especially under time pressure, the room gravitates toward the concrete and seemingly actionable, at the expense of the exploratory and uncertain. Someone says “we should add monitoring for this,” and the conversation shifts from understanding what happened to debating what to build. Once that shift happens, it’s hard to get back.
Meanwhile, the broader audience sits passively through a working discussion that wasn’t designed for them. The observers are theoretically “learning,” but when the conversation is a detailed working discussion among the responders, observers tend to drift to Slack and email, half paying attention at best. The presentation function doesn’t just get less time in a combined meeting; it gets less attention.
And the tyranny of the one-hour calendar block hangs over everything (especially if your hour only has 53 minutes). The working discussion goes where the work takes it. You can’t predict how long it needs based on the severity or complexity of the incident. Sometimes there’s a lot to learn from a small incident; sometimes there’s surprisingly little to discuss about a big one. A one-hour combined meeting trying to do the work of three distinct functions will likely shortchange all of them.
A diagnostic, not a prescription
The three-meeting frame isn’t a prescription to hold three meetings for every incident. Even at companies with the most mature incident practices, most incidents get a single meeting. That’s fine.
The frame is a diagnostic tool. If your review meetings feel rushed, performative, or dominated by action items, the problem might be that you’re asking one meeting to do the work of three. Recognizing the three functions helps you protect the one that the other two depend on (the working discussion) when they share a calendar invite, and invest in separate meetings for the incidents that warrant it.
Protecting the learning conversation
Understanding without follow-through is just conversation. But follow-through without understanding is just busywork. The action items that come out of a review are only as good as the understanding that produced them.
When you do hold a combined meeting, the simplest tool for protecting the learning conversation is to explicitly defer discussion of action items. “We’re going to defer discussing action items until the last fifteen minutes. If something comes up that feels like an action item, note it and we’ll come back to it.” Then enforce the boundary. During the working session, when someone says “we should add monitoring for this,” the facilitator says “noted; write that down so we can come back to it.” The first few times feel awkward. It gets easier, and the room gets better results.
In my experience, which is shared by other leading practitioners in the LFI (learning from incidents) community, teams generate fewer and better action items when they let the understanding generated in the working session settle and marinate a bit before they start digging into “what needs to change?” When people have time to sit with the understanding before jumping to “what are we going to do about this?”, they move past the reactive fixes and toward improvements that address broader patterns. If possible, you should defer the action items discussion until 24 hours after the working meeting; that’s not always practical, but the separation produces higher-quality outcomes.
The pattern is older than software
Separating these functions has parallels in other fields. The NTSB (the U.S. National Transportation Safety Board) separates its investigation from its public hearings from its final recommendations. Hospitals hold weekly morbidity and mortality conferences where cases are presented to the broader department, informed by detailed case review that happens separately. In both fields, the investigation, the discussion, and the recommendations are distinct phases. The principle applies whether you’re investigating a plane crash, a surgical complication, or a database outage.
None of this is exotic or expensive. It’s a matter of recognizing that a single meeting is trying to do three different jobs, naming those jobs, and deciding which one matters most when they compete.
For most incidents, this means giving the working discussion room to breathe, and keeping action items from taking over before understanding has had a chance to develop.
I’m writing a book on Incident Management for DevOps and SRE. Sign up to be notified when it’s available.
If your company needs help building or improving its incident management capabilities, my consulting practice is Great Circle.
by Brent Chapman | May 5, 2026 | Uncategorized
Modern AI tools can produce a competent-looking post-incident review document from a Slack channel transcript and a few prompts. The output will be pleasingly formatted, with a timeline, a list of contributing factors, and a set of action items. It will read coherently, and it will arrive faster than a human-written review would have, with less engineer time spent producing it. For a manager looking at the post-incident review process and seeing engineers grumble about the time it takes, this is tempting.
The catch is that the document was never the point of the review. The real learning comes from analyzing the incident while writing the document, not reading it; the document at the end is the residue of the learning. It’s like studying; you learn a lot more from working the problem sets than you do from just reading a classmate’s summary.
Three layers of learning
The learning happens at three layers: readers of the published document, the writers individually, and the writers as a group.
Readership is the most visible layer, and radiates outward when the document is published. Colleagues throughout the company read the review, see how it says the system behaved and how the team supposedly handled the incident, and perhaps update their own understanding of what’s possible. Most of them weren’t in the incident, so for them, the document is the incident. Their learning is downstream of the writers’ analysis, and weak analysis produces shallow lessons; readers get less than they could have, and some of what they get may be flat-out wrong.
Each writer ends up with a more thorough understanding of the incident than they started with. They start to write “the deploy caused the outage” and realize, as they trace the sequence, that the deploy only surfaced a problem that was already lying in wait. They find themselves describing the dashboard as “down” and stop, because the dashboard wasn’t actually down; it was up, but showing data from the wrong cluster, which is why nothing made sense to the responders for the first eighteen minutes. They write “the team decided to…” and stop, because the team didn’t decide; one person made a call and the others went along, and the gap between those two things turns out to matter.
The writers also learn from each other. Responders fill in their slices of the timeline; the architect annotates the contributing factors; customer success writes the impact section. As they go, someone catches a gap, someone corrects a misremembered moment, a disagreement surfaces in the comments and leads to an enlightening discussion. By the time the writing is done, the group has a grasp of what happened that no individual writer had alone. They built it from reconciling what each of them separately knew.
What AI does to each layer
When AI writes the document, each of these layers fares differently, and none of them fares well.
Readers are still readers. They open the document, take it in, and maybe update their understanding based on what they read. But what they’re absorbing now is the AI’s synthesis, with no human pressure-testing behind it. It may or may not be right, or get to the deeper issues that a group of writers might have uncovered. The document looks like a review, and readers absorb it like a real review. Whether they’re learning anything true or useful is now a function of how well the AI happened to do, with no way to tell from the outside.
There are no writers when the AI does the writing, so there’s no individual learning from the writing process. No one stops mid-sentence to discover that the deploy only surfaced a problem already lying in wait; no one finds that the dashboard was up but showing wrong-cluster data; no one writes “the team decided to” and stops to reconsider. The kind of learning that comes from working through the evidence sentence by sentence doesn’t happen when no one is doing it.
And without writers, you clearly can’t have “writers learning from each other.” The AI conjures up a plausible-sounding narrative from whatever it was given. No one catches a gap; no one corrects a misremembered moment; no disagreement surfaces in the comments to lead to an enlightening discussion. Any tension between what different people actually thought is gone before anyone could surface it.
So you end up with a polished artifact. Your contributing factors are the AI’s guess at what’s plausible, not your team’s hard-won understanding. Your timeline is a transcript reorganization, not a reconstruction. Your “lessons learned” come from the AI pattern-matching against incidents in its training data, not against the ones your company actually had. The document looks like a review, but it’s a fantasy.
You can automate production of the review document. You can’t automate the understanding that the process was supposed to produce. Automating the writing away automates the learning away.
Where AI legitimately helps
This isn’t a case for keeping AI out of the post-incident review process. Rather, it’s a case for being clear about where AI helps the engineers do the work and where it does the work for them. Mechanical support is genuinely useful. Substitution for human thinking is not.
Specific places AI earns its keep:
- Collating raw material. Pulling content from multiple Slack channels and threads into a unified view, transcribing voice channels (either real-time or recorded), gathering the screenshots and graphs that got posted in-channel during the incident. The grunt work that gives writers a clean starting point.
- Format and copy editing on a draft a human has written. Tightening prose, suggesting clearer phrasings, catching the inconsistencies that survive a human edit pass. AI is good at this, and using it here saves time without taking anything away from the writer’s engagement with the material.
- Surfacing gaps. “Your timeline jumps from 14:46 to 15:12 with no entries. Was anything happening then?” That’s a useful prompt for human writers, not a substitute for them.
- Cross-referencing past incidents. “Three other incidents in the last six months touched the same service; here are the links.” Pattern-matching across a library of past reviews is exactly the kind of mechanical work AI is well-suited to. (This one requires that your library of past reviews actually exists and is structured in a way the tool can search, which is a separate problem worth solving on its own merits.)
AI handles mechanical work that supports the writers. The writers do the thinking. The moment you let the tool do the thinking (generating the contributing factors, drafting the lessons learned, writing the narrative itself), you’ve automated away most of the learning, and arguably the most valuable parts.
The right question for the manager
If you’re an engineering leader evaluating an AI tool that promises to help with post-incident reviews, the question isn’t “does this tool produce a good-looking document faster?” All of them do that, but appearance alone shouldn’t be your criterion. A much better question is “does this tool support my engineers in doing the writing, or does it replace them in doing it?”
Tools in the first category save real time on the parts of the work that don’t produce learning. Tools in the second category save your engineers from the activity that the post-incident review exists for. They give you a polished artifact and an empty experience. The same incidents keep happening, but hey, now you have a faster pipeline for marking off the “Write Post-Incident Review” checkbox.
Here’s a clarifying way to think about it: you could throw the post-incident review document away after writing it and still get the vast majority of the value out of the process. The document is like the scribblings on a whiteboard after a productive working session: interesting, yes, and maybe worth snapping a photo of, but the real value is what leaves the room in the heads of the people who were there. You don’t actually want to throw it away (the document does real work, both immediately and over time, as part of the library of past reviews), but knowing that you could is the right reference point for thinking about which tools genuinely help the process and which ones quietly hollow it out.
AI can produce a good-looking incident review document, but only your engineers can produce the understanding behind a truly good one. Adopt tools that support that distinction; the ones that don’t will leave you with a stack of polished artifacts, but without much actual learning.
Post-incident reviews are one of several topics covered in my forthcoming book, “Incident Management for DevOps and SRE.” Learn more and sign up for updates at im4ds.com.
Need help preventing, preparing for, responding to, and learning from incidents? That’s the focus of my consulting practice at Great Circle.
Recent Comments