Outages take the weekend off

Stackpulse follows the official status pages of about 9,800 services. Between 28 September and 13 October, 3,671 of them reported at least one problem. Most were small and short: 1,662 reported a problem on a single day and were fine the rest of the time. Twenty reported one every single day.

When we lined the days up, the pattern was hard to miss.

Saturdays and Sundays are quiet

On a weekday, somewhere between 600 and 800 services report a problem of some kind. On the first weekend in October it was barely more than 300, a drop of more than half. The second weekend was less dramatic, partly because we added about 880 status pages to the set that Saturday, but it was still about a third below the days on either side.

Every day here counts a service once, whatever it reported: a minor issue, a major outage or a critical one. Maintenance doesn't count.

Big outages happen Monday to Thursday

The daily count includes a lot of noise, so we also looked only at the outages that matter to most people: a major or critical outage lasting 20 minutes or more, at one of about 350 well-known services. There were 115 of those between 26 September and 13 October.

98 of the 115 started between Monday and Thursday. Fridays averaged 3.5, Saturdays 2 and Sundays barely more than 1.

The Friday number is the one we'd be most careful with: it's two Fridays, one with a single outage and one with six. But it fits what a lot of teams already practise, which is not shipping big changes on a Friday afternoon.

And in the US working day

61 of the 115 outages, just over half, started in the seven hours from 13:00 to 19:59 UTC. That's 9 in the morning to 4 in the afternoon in New York, and the afternoon in Europe. The single busiest hour was 13:00 UTC, with 15.

The quietest stretch was the early hours of the European morning: 03:00 and 06:00 UTC had none at all.

What this means, and what it doesn't

A status page shows what a company chose to report, so this is a picture of reported outages, not of every failure. Two explanations fit the pattern, and we can't tell them apart from the outside:

• Things break when people change them. Deploys, migrations and config changes happen during working hours, and a lot of outages start with a change.
• Problems get reported when people are around. A minor issue at 3 am on a Sunday may be fixed before anyone writes it up.

Both are probably true. If you're on call for something that depends on a lot of SaaS, the practical version is the same either way: the riskiest time for your vendors is a Tuesday or Thursday afternoon in Europe, and the calmest is the weekend.