Who Checks the Checker? Automation Is Creating More Checking Work, Not Less

On Thursday afternoon, 12 November 2026, Outlook, Teams, Copilot, SharePoint and Microsoft's Defender security tools went down for people in 74 countries. By Friday morning it still wasn't fully fixed. Servers that came back overnight went down again.

Here in the UK, the effects reached well past the office. Some GP practices asked patients to phone for urgent matters because email wasn't reliable. Property completions were held up because solicitors, lenders and brokers couldn't exchange documents. A railway company told customers to use its app because ticket emails weren't arriving.

Microsoft has said there's no sign of a cyberattack, and it has promised a full post-incident report once the service is stable. So this article doesn't claim to know the root cause. What interests me is something smaller in the public updates, and what it has in common with other incidents.

The thermometer that sent healthy people home

Microsoft's explanation changed over the first day. It mentioned elevated load first, then servers becoming unexpectedly unavailable. Later it pointed to automated health checks that were taking servers out of service, and to a process for setting up secure connections that had become overwhelmed.

Let's treat that as provisional until the report arrives. Even so, the shape is worth understanding.

A health check is a small piece of automation that asks each server "are you well?" and removes the ones that answer badly. It exists to protect the system. But if the check itself is wrong, or the servers are slow because of load rather than truly sick, the check starts sending healthy machines home. The remaining servers pick up their traffic, slow down in turn, and get sent home too. The safety net becomes the outage.

Well-built systems plan for this. One common rule is called a panic threshold, or failing open: if the checker says more than a set share of servers are sick at the same moment, it assumes the checker is the likelier problem and keeps sending traffic to every server. "Everything failed at once" is far less likely than "my thermometer is wrong."

That rule doesn't write itself. Someone has to know it's needed, choose the threshold, and understand what it costs.

This isn't the first checker with a gap

The pattern shows up again and again.

• July 2026, Microsoft 365 again. Routine network maintenance was automated. A bug in the system that turns maintenance requests into instructions marked extra network devices as part of the job, and routes were removed from more devices than intended. A safety check was in place: it confirmed that one of two redundant paths stayed healthy before the work began. It checked the automation's output, though, not whether that output matched what the engineers had asked for.
• October 2025, AWS. A latent race condition in DynamoDB's automated DNS management let an outdated plan overwrite a newer one, and a cleanup process then deleted it. The main regional endpoint was left with no addresses at all. Two automated helpers each did their own job correctly by their own rules, and together they produced an empty answer.
• July 2024, CrowdStrike. A content update reached millions of Windows machines after an automated content validator approved it. The validator had a bug of its own, so the one gate meant to stop a faulty file let it through.

None of these happened because automation is bad. Each one is a system that worked many thousands of times before. But every time we automate a step, we add a check around it, and that check is code too. It can be wrong. It has assumptions. And someone has to understand what it's actually checking, which isn't always what it was meant to check.

Automation moves the work. It doesn't remove it

Every automated step needs its checking spelled out: thresholds, validators, rollback rules, health checks, and alerts that tell a person the truth. Nothing gets checked unless someone has decided how it will be checked.

So automation doesn't remove the need for careful thinking. It asks for that thinking in a new place, and usually a harder one: from "is this server fine?" to "is my definition of fine still right when everything is under load at once?"

The same thing is happening with AI-written code, and the numbers are clear. In Sonar's State of Code developer survey (January 2026, more than 1,100 developers):

• Developers said 42% of the code they commit now comes from AI, and they expect that to pass 65% by 2027.
• 96% don't fully trust that code.
• Only 48% always verify it before committing.
• 38% say reviewing AI code takes more effort than reviewing a colleague's.

Sonar's own name for this is a verification bottleneck. Code is being produced faster than people can check it. That gap doesn't close because a tool writes faster. It closes when someone checks the work.

Decisions made far from the work

Meanwhile, US tech companies announced 165,925 job cuts in the first nine months of 2026, up 54% from a year earlier, according to Challenger, Gray & Christmas. AI is often given as part of the reason.

I understand how that decision looks on a spreadsheet. A headcount line shows a cost. What it doesn't show is the person who knows why the panic threshold is set at 40%, or why one maintenance job must never touch both network paths, or which alert has gone quiet for six months because it was muted during a migration and never turned back on. That knowledge doesn't live in the code. It lives in people, and it leaves with them.

The decisions are usually made far from the engineering, by people who can't see what the checking work is until it's gone. That isn't a personal failing. It's a visibility problem. When checking works, nothing happens, so it looks like nothing is being done.

The same CNBC report, based on Randstad's Tech Talent Report 2026, shows another trend. Banks, healthcare and life sciences companies, and other non-tech employers are recruiting the engineers that tech firms let go, and paying more for them: about 13% more at banks and up to 17% more in healthcare. Postings that ask for AI skills grew fivefold in a year. The organizations that have to live with the results of their software, where a silent failure means a delayed payment or a missed appointment, are the ones looking for people who understand it.

Where I come from

For eighteen months, every IT job I applied for came back as a no. It was a discouraging stretch, and at the time it was hard not to read it as a verdict on what I could do. So I built my own business instead. Weeks like this one make me more sure of that choice, not less. Small businesses are exactly the ones who can't absorb a day without email, and who rarely have anyone whose job is asking "what does this check actually check?"

What the growing demand looks like

If you're an engineer feeling discouraged by the news, here's where I see the work growing, not shrinking:

1. Verifying AI-written code. Reading it, testing it, and being accountable for it. The tools are fast, and someone still has to know whether the result is right.
2. Checking the checkers. Health checks, validators and safety gates need their own design: what they compare against, what they do when they disagree with everything at once, and who hears about it.
3. Comparing output with intent. The July incident shows the difference between "the automation's output passed" and "the automation did what we asked." Guardrails that compare against the original request are design work, and people do it.
4. Configuration review. Many large incidents begin with a settings change. Reviewing configuration is quiet, careful work that rarely makes headlines until it's missing.
5. Error messages and alerts that tell the truth. When something goes wrong, the people affected need to hear about it clearly and early, not a day later through a news site.
6. Human review where decisions reach people. Wherever an automated result changes someone's money, health, travel or home, a person who understands the system should be able to look at it and step in.

None of this is glamorous, and most of it is invisible when it works. That's exactly why it gets cut, and exactly why it comes back.

The checker is part of the system

Automation is a powerful tool, and I build with it every day. But every automated step comes with a question attached: who checks the checker? The answer is still an engineer, and as automation grows, the answer matters more.

Software should never fail a person in silence. And the people who make sure it doesn't are needed more than ever.