503 Service Unavailable / SERVER_UNAVAILABLE / The Salesforce server is temporarily unavailable

HTTP 503 from a Salesforce endpoint means the platform's load balancer or instance temporarily can't service requests. The cause is rarely your code; it's something on the platform side.

The first move

Check Salesforce's Trust Status page. Find your org's instance (usually shown at login as mycompany.my.salesforce.com → instance like NA189 or EU45). The status page shows:

• Active incidents — major degradations the platform team is working on
• Scheduled maintenance — planned downtimes (your release window, security patches)
• Recent service disruptions — anything in the last 24 hours that explains why you're seeing 503s now

If the instance is green, the issue might be your specific request, not the platform. If it's red or yellow, the issue is platform-side and you wait.

When 503s are intermittent

Some 503s are transient — happen for a few seconds, then stop. Causes:

1. Instance failover — Salesforce occasionally migrates your org between data centres. Brief 503 window during cutover.
2. Brief load spike — another tenant on your shared instance hammered it; the load balancer rejected some requests to protect the rest.
3. Connection pool exhaustion — your integration hit a momentary cap of connections; subsequent retries succeed.

For these, the right behaviour is retry with backoff:

async function callWithRetry(url, opts, retries = 3) {
  for (let i = 0; i < retries; i++) {
    const res = await fetch(url, opts);
    if (res.status !== 503) return res;
    await new Promise(r => setTimeout(r, Math.pow(2, i) * 1000));   // 1s, 2s, 4s
  }
  return await fetch(url, opts);   // final attempt
}

Don't loop forever — that turns a transient outage into a self-DDoS.

When 503s are sustained

If your call gets 503 for more than a few minutes:

1. Check the Trust page for an active incident (above)
2. File a support case with the request URL, full HTTP response (including Sforce-* headers), and a timestamp
3. The case routes to Salesforce's infrastructure team

The platform team can read internal logs from your request ID and tell you whether the failure is on your tenant, on the instance, or platform-wide.

When 503s are concentrated on one endpoint

If /services/data/v60.0/query is fine but /services/data/v60.0/sobjects/Account is 503ing, it's not full-instance — it's a specific service tier. Common during release rollouts where one service is being patched.

A misleading 503: API rate limits

The platform sometimes returns 503 when you've actually exceeded API rate limits (rather than the more correct 429 Too Many Requests). Check your API Usage in Setup → System Overview. If you're at >80% of your daily API call cap, the platform may shed your traffic.

What to not do

Don't keep increasing retry counts. A request that's 503'd 10 times will 503 the 11th. Either:

• Fail visibly so a human knows something's wrong
• Switch the workload to a queueable that polls for resolution

Background jobs that retry forever often mask incidents — your team finds out only when an SLA breach occurs days later.