On September 16, 2026, Salesforce went down. Globally. On day two of Dreamforce.
While tens of thousands of people in San Francisco were hearing about AIforce, Agentforce, and Headless 360, customers around the world were staring at login errors and spinning loaders. Developers refreshed the Trust status page. Deployments stalled. Standups turned into “is it just me?”
I didn’t notice.
By the time a colleague pinged me, I had already written, tested, and refactored all the Apex I planned to finish that day. Not because I got lucky, but because my development loop doesn’t need an org to be online.
Here’s what happened, what it reveals about how we build on Salesforce, and how to make sure the next outage doesn’t stop you.
What happened: the September 16, 2026 Salesforce outage in brief
Based on Salesforce’s status updates and press coverage at the time of writing:
- ~07:50 UTC: The service disruption began, affecting Core Service.
- Scope: Hundreds of instances across all regions, including the US, UK, Germany, France, Japan, and India.
- Symptoms: Severe delays, intermittent errors, and users unable to log in or access services. Even new support cases were hard to submit.
- Cause (preliminary): Salesforce pointed to requests stalling on an internal login service, which exhausted available capacity.
- Late morning UTC: A fix was validated and rolled out, but some instances took longer to recover, and some customers reported scheduled jobs not running as expected afterwards.
Check status.salesforce.com for the official root cause analysis once it’s published.
The timing couldn’t have been worse: the biggest week of the Salesforce year, with the entire ecosystem watching.
The real problem: your Salesforce dev loop has a single point of failure
Look at a typical Apex developer’s inner loop:
- Write code in VS Code or IntelliJ
- Deploy to a scratch org or sandbox
- Run tests in the org
- Wait
- Dig through debug logs, fix, repeat
Only step 1 is local. Your compiler, test runner, and debugger all live in Salesforce’s data centers.
On a normal day, that means slow feedback. On a day like September 16, it means zero productivity. And Salesforce outages aren’t one-offs. There have been major incidents in 2019, 2021, 2023, and 2025, from faulty permission scripts to DNS changes.
No other ecosystem accepts this. Java developers don’t stop coding when Maven Central blips. Go developers don’t stop testing when AWS has a regional incident. Local-first development is standard everywhere, except Salesforce.
How to develop and test Apex without a Salesforce org
For the past months I’ve been building and using Nimbus, a local toolchain for Apex. It lets you run and test Apex on your machine, like any other language.
Here’s what my outage morning actually looked like:
1. Running Apex unit tests locally
No deployment, no test queue. Feedback in seconds instead of minutes.
2. SOQL and DML against a real database
Nimbus embeds PostgreSQL, so queries and inserts hit a real data layer, not brittle mocks.
3. Testing Platform Events offline
A local Pub/Sub gRPC server means event-driven Apex works without an org.
4. Measuring test quality with mutation testing
Coverage tells you code ran. Mutation testing tells you whether your tests would catch a bug. (More on this below.)
5. Tracing instead of debug logs
OpenTelemetry traces show exactly what executed, without the debug log scavenger hunt.
When the platform came back, the only step left was the deployment.
Why 75% Apex code coverage isn’t enough
Salesforce requires 75% coverage to deploy to production. But look at this test:
@IsTest
static void calculatesDiscount() {
Decimal result = PricingService.applyDiscount(100, 0.2);
System.assertNotEquals(null, result);
}
Enter fullscreen mode Exit fullscreen mode
It fully covers applyDiscount. It also passes if the method returns 100, 80, or -42.
Mutation testing fixes this blind spot. It deliberately changes your code (flips > to <, swaps constants, deletes statements) and reruns your tests. If nothing fails, a “mutant survived,” and you’ve found a gap.
Running this in an org would take hours. Locally, it’s part of the normal loop.
Local-first matters even more in the Agentforce era
This year’s Dreamforce was all about agents: Agentforce, Agent Script, Headless 360, MCP, vibe coding. AI is writing more and more Salesforce code.
That raises a question nobody on stage answered: where does AI-generated Apex get verified before it touches a real org?
If every check needs a live org, your AI agents stall during outages just like you do. And letting agents iterate directly against sandboxes is slow and risky.
Nimbus ships an MCP server, so coding agents like Claude Code can run tests, check mutations, and verify Apex locally. The org becomes the place you deploy proven code, not the place you experiment.
Key takeaways for Salesforce teams
- Outages will happen again. Plan for them like any other dependency failure.
- Decouple your inner dev loop from platform availability.
- Coverage is a deployment gate, not a quality metric. Use mutation testing.
- CI pipelines get more reliable when unit tests don’t need an org for every run.
- AI agents need a safe, local sandbox to verify their code.
FAQ
Was Salesforce down on September 16, 2026?
Yes. Salesforce reported a global service disruption starting around 07:50 UTC, affecting instances across all regions during Dreamforce 2026.
Can you run Apex tests without a Salesforce org?
Yes, with a local toolchain like Nimbus, which runs Apex, SOQL, DML, and Platform Events on your machine.
How do I keep developing during a Salesforce outage?
Move your write-test-refactor loop local. Only deployment and integration testing truly need the org.
Try it
Nimbus is available for free for everyone, and Pro features are free during the launch period. If the outage cost you half a day, spend twenty minutes setting up a loop that won’t care next time.
How did your team handle the outage? Were you stuck, or did you have a workaround? Tell me in the comments. 👇
Run your Salesforce development without an org. Run it with Nimbus.