Website outages get resolved just as fast in August as they do in November. I went looking for the opposite: the summer slowdown everyone assumes is there once the people who fix things are away. It isn't in the data we collected, covering 1.8 million confirmed outages across tens of thousands of websites.
Over the last 17 months — two summers, one of them with a completed August — the median time to resolve an outage held at roughly two minutes. That's not one average for the whole period. It's the median for each month on its own, holiday months included. Last August, the emptiest month on most office calendars, was one of the fastest months in the set. Summer as a season came in slightly ahead of the rest of the year, not behind it.
That surprised me, and I suspect it would surprise most people running infrastructure.
The median is doing the work here, and it's worth being clear about why. It's the midpoint outage, the typical one. Monthly averages move for reasons that have nothing to do with seasons: one marathon incident, a certificate that expired on a Friday night and got noticed on Monday, drags a whole month's mean with it. A mean can sit several times above the median in the same dataset.
So if you want to know whether your recovery is degrading in summer, look at the middle of the distribution and at the tail separately. Judge recovery on the typical outage, then go and look at the worst one on purpose. A blended average mostly tells you how unlucky you got.
Why the line stays flat is the more interesting question, and the data doesn't answer that on its own.
Some of it is automation. Platforms restart processes, health checks pull a bad instance out of rotation, a deploy rolls itself back. None of that knows what month it is.
But plenty of fixes still need a person: a config change reverted, a queue drained, a stuck deploy killed by someone who knows which one it is. Somebody opened a laptop. Nothing in the numbers tells me how that split moves between July and November. Only that the result doesn't budge.
My read is that in a large organization, a flat summer is a staffing outcome. You've got follow-the-sun coverage, a documented rotation, someone who's paid to be reachable. Summer cover is a scheduling exercise that somebody owns in advance.
Most of the web isn't that. It's small development teams and agencies where keeping the site up was never formally assigned to anybody. One person has the alerts on their phone and has never been asked whether they mind. I think a good part of that flat August is them, answering.
If it is, the number is worth less than it looks. A resilience figure that holds because one unnamed person never quite logs off isn't in the runbook or the on-call budget, and it doesn't show up on a dashboard. It looks exactly like automation working, right up to the August where that person is genuinely unreachable, or has left.
I spent years as a sysadmin, so my first reaction to this was pride in the people doing the work. What bothers me is the structure they're doing it inside.
There's a straightforward exercise here for anyone with a summer coverage plan. Take last month's incidents and write down who actually resolved each one. Not the person who owned the service on paper. The person who did the work. If the same name keeps appearing and that name isn't on any rotation, you've found the layer your uptime is resting on. That's worth knowing before you find out the hard way, and it's worth saying out loud to the person concerned, ideally alongside some form of thanks more durable than cake.