Should you declare an incident for a vendor outage?

Yes. You cannot fix the fault, but the coordination, communication, workaround, and impact recording are all real work that needs an owner. Treating it as somebody else's problem produces the worst outcome: everyone aware something is broken and nobody coordinating the response.

Why do status pages lag the actual outage?

Because they are communication artefacts with a human approval step, and updates are written carefully for a broad audience. Your users and your own synthetic checks against the vendor's API will both detect a problem sooner, which is why detection should rest on signals you control.

What was the cause of the September 2026 Salesforce outage?

No formal root cause analysis was published in the reporting available at the time. Salesforce's status updates described requests stalling while waiting on an internal login service and consuming available server resources, and later referred to increased load on a core component limiting request capacity.

How do you review an incident with no vendor postmortem?

Review your own response rather than their fault. How long until you knew, whether your workaround functioned, whether communication reached people, and what your integrations did while the vendor was degraded. All of that is within your control and needs no document from them.

What should you do when a vendor service recovers?

Do not treat the status page as the end. Confirm your own checks pass, drain queued work, and rerun failed jobs with attention to idempotency, since duplicate records commonly appear in the first hour. Then reconcile record counts against an expected baseline before closing.

Running an Incident You Cannot Fix

During a vendor outage you cannot diagnose or repair the fault, so the incident work is communication, workaround, and impact recording. Assign an incident commander anyway, track affected internal services, capture what work was blocked, and do not close the incident when the status page turns green.

A recent example, and what was actually knowable

On 16 September 2026 Salesforce experienced a broad service disruption. The Register reported the outage beginning around 08:30 UTC and service recovering later the same day, with hundreds of instances affected across multiple regions, and reported symptoms including severe delays, intermittent errors, failures to access services, inability to create support cases, and scheduled jobs not running. Salesforce Ben also covered it, noting it coincided with the company's own conference.

The explanation available at the time came from status updates rather than an analysis. Salesforce's status wording described requests stalling while waiting on a response from an internal login service and using up available server resources, and a later update referred to increased load on a core system component limiting its capacity to process requests. No formal root cause analysis was published in the period covered by that reporting, and accounts of total duration differ between outlets.

That is the normal information environment for a vendor outage, and it is worth internalising. You get a symptom description written for a broad audience, in progress, with no timeline commitment. Treating that as insufficient is correct; expecting it to improve during the incident is not.

Why status pages are the wrong trigger

A status page is a communication artefact with a human approval step, so it lags the failure by design. Your users will report problems first, and your own synthetic checks against the vendor's API will detect it before the page changes. The practical consequence is to build detection on the signals you own: a periodic authenticated call to the services you depend on, alerting on latency and error rate. When the vendor is down, you want to be telling your organisation, not discovering it from them.

What the incident process should still do

Declare it and name a commander. The instinct is to treat a vendor outage as not ours. That produces the worst version: everyone knows something is wrong, nobody is coordinating, and the same question gets answered fifty times in chat. The coordination work exists regardless of who owns the fault.

Communicate on a schedule, not on progress. You have no progress to report, which is exactly why a fixed cadence matters. A brief update every thirty minutes saying the vendor has not changed status and the workaround remains in place stops the queries and prevents rumour filling the gap.

Translate vendor status into internal impact. Nobody internally cares which component degraded. They need to know that a specific process is blocked, which workaround applies, and whether data entered now will be lost. That translation is the incident commander's main output here.

Deploy the workarounds you prepared. Queueing work for later entry, falling back to a manual process, pausing jobs that will fail and retry destructively. These only exist if someone designed them before the outage, which is the argument for doing that for your few critical dependencies.

Watch for your own retry behaviour making things worse. Integrations that retry aggressively against a degraded service extend the outage for everyone and can cause duplicate writes on recovery. Knowing which of your jobs will hammer a recovering vendor, and having a way to pause them, is a concrete piece of preparation.

Record blocked work as you go. Which teams lost how much time, which customer commitments slipped. This is difficult to reconstruct later and is the only quantified input you will ever have for contract conversations.

Recovery and review

Do not close when the status page resolves. Recovery is when your own checks pass and the backlog has drained. Queued work needs entering, failed jobs need rerunning with attention to idempotency, and the first hour after a recovery is when duplicate records appear.

Reconcile rather than assume. After a partial outage, some writes succeeded and some did not. Checking counts against an expected baseline is tedious and much cheaper than discovering the gap in a month.

Hold your own review without a vendor analysis. You are not reviewing their fault, you are reviewing your response: how long until you knew, whether the workaround worked, whether communication landed, what the retry behaviour did. All of that is within your control and none of it needs their document.

Write down the dependency exposure you just learned. Most organisations discover during an outage that something they considered peripheral was load-bearing. That finding is the most valuable output of the incident, and it decays quickly once normal work resumes.

Set expectations about analysis honestly. Many providers publish detailed writeups; many publish nothing beyond status updates. Your architecture should not depend on which kind you have, and if a dependency is critical enough that you need their internal detail to operate safely, the real finding is the dependency.

Frequently asked questions

Should you declare an incident for a vendor outage?: Yes. You cannot fix the fault, but the coordination, communication, workaround, and impact recording are all real work that needs an owner. Treating it as somebody else's problem produces the worst outcome: everyone aware something is broken and nobody coordinating the response.
Why do status pages lag the actual outage?: Because they are communication artefacts with a human approval step, and updates are written carefully for a broad audience. Your users and your own synthetic checks against the vendor's API will both detect a problem sooner, which is why detection should rest on signals you control.
What was the cause of the September 2026 Salesforce outage?: No formal root cause analysis was published in the reporting available at the time. Salesforce's status updates described requests stalling while waiting on an internal login service and consuming available server resources, and later referred to increased load on a core component limiting request capacity.
How do you review an incident with no vendor postmortem?: Review your own response rather than their fault. How long until you knew, whether your workaround functioned, whether communication reached people, and what your integrations did while the vendor was degraded. All of that is within your control and needs no document from them.
What should you do when a vendor service recovers?: Do not treat the status page as the end. Confirm your own checks pass, drain queued work, and rerun failed jobs with attention to idempotency, since duplicate records commonly appear in the first hour. Then reconcile record counts against an expected baseline before closing.