Three Outages in Four Days: Testing the Changes That Are Not Code

Three of the most widely used business platforms went down within four days in September 2026, and none of the outages began with a new feature. GitHub was hit by a background data cleanup job, SharePoint Online by a configuration change, and Salesforce by a failure in its login path. For any business that ships software, the lesson is that the riskiest changes are often the ones nobody thinks of as a release, and so nobody tests them like one.

The short answer

Test every change that can reach production, not only code. Configuration changes, scheduled jobs, data migrations and dependency updates need the same path as a feature: a review, a test against realistic data, a gradual rollout and a rollback you have actually practiced. Then test what your own product does when a service it depends on fails.

What happened in September 2026

GitHub: a safeguard watching the wrong number

On September 13, from 08:43 to 10:44 UTC, about two dozen GitHub services returned errors, including Issues, Pull Requests, Actions and Pages. GitHub's incident report says an internal data cleanup job started writing to a shared database cluster at 07:33 UTC. The job had a pacing safeguard, but it watched only replica lag, which stayed low. Meanwhile the load built up on the primary database until it ran out of connections. Retry logic then kept resending the failed writes, which kept the database saturated.

Every part of that worked as designed. The safeguard was real. It measured the wrong thing, and nobody had tested the job against the condition that actually failed.

Salesforce: a dependency in the login path

On September 16, Salesforce customers lost access for roughly seven and a half hours, starting around 07:50 UTC. Salesforce said requests were stalling while waiting on an internal login service. Its early updates described an external dependency failure affecting a legacy login server, and later that core components were under increased load. Its infrastructure provider confirmed there was no problem on its side. As of early October, reporting noted that Salesforce had not yet published its full root cause, so I will not guess at one. What is already clear is that a single service in the sign in path could stop customers from working at all.

SharePoint Online: a configuration change

The same day, from 16:04 to 17:30 GMT, some SharePoint Online users saw blank sites and an error instead of their pages. Microsoft attributed it to a configuration change affecting how its servers deliver the code used to render pages. It rolled the change back, and said it was reassessing how it validates and deploys configuration changes.

That last sentence is the one I would underline. A company with Microsoft's resources found that configuration was moving through a lighter process than code.

Why changes that are not code slip through

Most testing effort in a small or midsize business sits around new features. Pull requests get reviewed, a test suite runs, and someone clicks through the new screen. Other kinds of change often skip all of that:

• Configuration. Feature flags, environment settings, pricing tables and permission rules are edited in a dashboard and take effect immediately.
• Scheduled and background jobs. Cleanup tasks, imports, syncs and reports run against production data that is far larger and messier than any test copy.
• Data migrations. A change to a table can lock it or slow it for every user at once.
• Dependencies. A payment processor, a sign in provider, an email service or an AI model can change or fail without any action on your part.
• Retries. Code that retries a failed request can turn a short slowdown into a long outage, as GitHub's report showed.

None of these show up on a feature roadmap, so none of them get a test plan.

How to test the changes that are not code

1. List your change types. Write down every way production can change: deployments, configuration edits, scheduled jobs, migrations, vendor updates. For each one, name who can make it and how it is reviewed today. Gaps show up quickly.
2. Put configuration through review. Store configuration in version control where you can, require a second person to approve changes, and record who changed what and when.
3. Run background jobs against production sized data first. A cleanup that finishes in seconds on a test database can run for hours on the real one. Measure the load it puts on the main database, not only on the copies.
4. Check the safeguard itself. If a job has a limit or a kill switch, test that it trips under the condition you are actually worried about. A safeguard that never fires in testing has not been tested.
5. Roll out gradually. Apply risky changes to a small share of users or one region first, watch error rates, then widen. Make the next step depend on the numbers, not the clock.
6. Practice the rollback. Time how long it takes to undo a configuration change or a migration. If nobody has done it, assume it will take longer than the outage you can afford.
7. Test your own app with a dependency down. Block the sign in provider, the payment service or the email service in a test environment and see what customers would see. A clear message and a saved draft are far better than a spinning screen.
8. Limit retries. Confirm that retries back off and stop after a set number, so your own code does not keep a struggling service down.

What to ask your vendors

You cannot test Salesforce or SharePoint yourself, but you can ask how the platforms you rely on handle this. Ask whether configuration changes go through the same staged rollout as code, where incident reports are published, and how quickly a root cause is shared. Subscribe to their status pages, and decide in advance what your team does when a core platform is down for a full working day.

The pattern to remember

Each of these reports describes a system that was working until something outside the normal release process changed it. Quality assurance is often treated as a gate in front of new features. September was a reminder that it also has to cover the switches, jobs and connections that change production every day without anyone calling it a release.

Getting help with release and change testing

HQ Labz helps businesses put QA and testing around everything that changes their software, including configuration, scheduled jobs and the services they depend on. It starts with a free discovery call and a written quote stating hours, price and timeline before any work begins.

Talk to us about testing your releases

Questions people ask

Why do configuration changes cause so many outages?

Configuration often takes effect immediately and skips the review, testing and gradual rollout that code goes through. A single wrong value can reach every user at once, as Microsoft's September 2026 SharePoint incident showed.

How do you test a configuration change before production?

Keep configuration in version control, have a second person approve it, apply it first in a test environment with realistic data, then roll it out to a small share of users while watching error rates, with a practiced rollback ready.

What is a post-incident review?

It is the report a provider publishes after an outage explaining what happened, why, how it was fixed and what will change. Reading other companies' reports is one of the cheapest ways to find gaps in your own testing.

How should my app behave when a service it depends on is down?

It should tell the customer clearly what is unavailable, keep any work they entered, and recover on its own when the service returns. Test this on purpose by blocking the dependency in a test environment.

Sources

1. GitHub Status. Incident with several GitHub services. September 13, 2026.
2. The Register. Microsoft configuration change leaves SharePoint pages drawing a blank. September 17, 2026.
3. CIO. Salesforce's massive outage exposes the hidden risks of cloud dependencies. September 16, 2026.
4. CX Today. Salesforce outage chaos: the week uptime lost its impact. October 4, 2026.
5. Webhosting.Today. GitHub, Salesforce and SharePoint went down in four days. Nobody attacked them. September 22, 2026.