Were we not monitoring for that?
Why this matters · What ‘yes, but’ means · Six questions · How we help · Sources
It’s the question asked in almost every post-outage review once the CIO or CTO joins the call, and it usually meets silence. The honest answer is almost always ‘yes, but’. Here is what the ‘but’ usually is, and what to ask before the next outage instead of after it.
The sources could not be loaded. Please reload the page.
Why this matters
said their most recent major outage cost more than $100,000
said it cost more than $1 million
of those with an impactful outage in the past three years say it could have been avoided with better management, processes or configuration (n=98)
Change is the usual trigger. In Uptime Institute’s 2026 survey, configuration and change management failures were the most common cause of major network outages (41%) and were behind about half of major IT system and software outages (51%).
Share of respondents citing each cause for their major outages of that type; outages can have more than one cause.
What ‘yes, but’ usually means
A change went in, but the process wasn’t followed.
Steps were skipped, and monitoring lost sight of the work. The team didn’t put its servers into maintenance, so alerts were muted or waved off as ‘just the change’. Or the work ran past its approved window, and when something really broke, nobody connected it to the change.
Every change should tell monitoring three things: when it starts, what it touches and when it is finished.
The data was there, but nobody watched the trend.
The metric was collected and graphed; the alert only fired at failure, not at the point where the trend made failure certain.
An alert fired, but into a queue nobody owns.
It was routed to a shared mailbox or a team that no longer runs that service.
It was one of hundreds.
The real warning was buried in noise, so it was skimmed past.
We watched the parts, not the service.
Every server looked healthy while customers couldn’t log in, because nothing measured what customers experience.
It came from someone else’s platform.
A cloud, SaaS or network provider failed, and nothing watched that dependency.
Six questions to ask before the next outage
- For our ten most important services, do we alert on what customers experience, or only on servers?
- Do our alerts warn us before limits are reached, based on trends, or only when they are crossed?
- Does every alert have a named owner, and how many alerts does that owner get in a week?
- After each major incident, do we record the warning sign we missed and add an alert for it?
- Which outside providers could take us down, and how would we know first?
- When a change goes in, does our monitoring know about it, so the first alert after a change points straight at it?
Problem management exists for exactly this: ITIL describes its aim as to
How we help
See how prediction works in practice →
Sources
Facts checked Oct 11, 2026.