Build1 publisher3 min readPublished
A stalled login service took four of the five Apex inner-loop steps offline
Salesforce Core failed globally on the second morning of Dreamforce 2026, and the standard Apex loop keeps its compiler, test runner and debugger inside the org. The only account of shipping through it comes from a toolmaker.
The Engineer · Build desk
What happened
- Salesforce's Core Service disruption began at about 07:50 UTC on 16 September 2026, the second day of Dreamforce in San Francisco.
- Hundreds of instances across all regions were affected, including the US, UK, Germany, France, Japan and India, with users unable to log in and even new support cases hard to submit.
- A fix was validated and rolled out late morning UTC, some instances took longer to recover, and some customers reported scheduled jobs that did not run as expected afterwards.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint An Apex team cannot buy its way out of this with more local hardware, because the compiler and test runner it uses belong to Salesforce, and the fastest available response to a login-path failure is to wait.
- exposure A deploy gate that measures executed lines lets teams ship suites that assert almost nothing, and the missing assertion surfaces as production behaviour rather than as a red build.
- decision Anyone pointing coding agents at Apex has to pick a verification target: sandboxes that inherit every platform incident, or a local runtime whose fidelity to the org they have to test themselves.
- cost Decoupling the loop means running a second Apex implementation plus a Postgres data layer on every developer machine, and owning every case where local green does not mean org green.
Steps two through five of a standard Apex loop run on someone else's computers. You deploy to a scratch org or sandbox, run the tests in the org, wait, then dig through debug logs [8]. The compiler, the test runner and the debugger all sit in Salesforce data centers [9]. Only the editor is local, which leaves four of the five steps needing a reachable org [10]. Salesforce's preliminary explanation put the disruption on requests stalling in an internal login service [5], and a session is the prerequisite for each of those four steps. The author points out that Java developers keep coding when Maven Central blips and Go developers keep testing through an AWS regional incident [22].
The one account of an uninterrupted outage morning comes with a product attached. The developer wrote: "Not because I got lucky, but because my development loop doesn't need an org to be online." [19] He builds Nimbus, a local Apex toolchain he has been using for months, which embeds PostgreSQL so queries and inserts hit a real data layer and runs a local Pub/Sub gRPC server for event-driven code [16][17]. When the platform came back, the step he had left was the deployment [24].
Deployment to production is where Salesforce enforces 75 percent coverage [11]. Coverage counts executed lines. The post's example test calls applyDiscount(100, 0.2) and asserts only that the result is not null, so it fully covers the method and passes whether the return is 100, 80 or -42 [12]. The discounted value is 80, so two of the three returns that satisfy the assertion are wrong [13]. An assertion that a Decimal is not null tests that the method returned. Mutation testing flips a > to a <, swaps constants and deletes statements, then reruns the suite; a mutant that survives marks a missing assertion [14]. The author says a mutation run inside an org takes hours, and that his local loop returns feedback in seconds instead of minutes [15][25].
This year's Dreamforce program was agents: Agentforce, Agent Script, Headless 360, MCP, vibe coding [23]. The author asked "where does AI-generated Apex get verified before it touches a real org?" [20] Nimbus ships an MCP server, so Claude Code and similar agents can run tests and check mutations without a sandbox [18].
For a green local run to say anything about production, the local engine's Apex semantics have to match the platform's, and the embedded Postgres layer has to answer SOQL and DML the way the org's storage does. Code that leans on org metadata, installed packages or per-instance configuration is where I would expect divergence to appear first. The post does not publish a parity list or a set of unsupported features. It does list four earlier Salesforce incidents, in 2019, 2021, 2023 and 2025, attributing them to causes including faulty permission scripts and DNS changes [21]. Salesforce's official root cause analysis is due on status.salesforce.com [7].
What to watch
- Salesforce's published root cause analysis on status.salesforce.com, and whether the login service's capacity exhaustion had a configuration trigger.
- Whether customers whose scheduled jobs missed their windows after recovery had to reconcile data by hand.
- Whether Nimbus publishes a parity list naming the Apex, SOQL and DML behaviour its local runtime does not reproduce.