When Salesforce Workbench suddenly stops logging in, REST Explorer returns an error, or a query that worked minutes ago begins timing out, the fastest path is not to keep clicking Retry. First determine which layer is failing: the Workbench web app, your browser or network, Salesforce authentication, your specific Salesforce instance, or the API request itself.
That distinction matters because Workbench is a community-maintained, web-based API utility rather than a fully supported Salesforce product. Salesforce explicitly says it does not maintain Workbench and recommends supported alternatives such as Salesforce CLI, Code Builder, and the Salesforce Extensions for Visual Studio Code. The Workbench project itself also describes the tool as maintenance-only. See Salesforce's Workbench replacement guidance and the original Workbench source repository.
Use this page as a practical reference when an outage or degraded service is suspected. The goal is to preserve evidence, avoid unnecessary retries, and decide whether to wait, change tools, or fix something local.
| Check | What to look for | What it tells you |
|---|---|---|
| Salesforce Trust | Incident, degradation, maintenance, or instance-specific impact | Whether Salesforce reports a platform-side problem |
| Workbench itself | Can the login page load? Does OAuth redirect correctly? | Whether the community-hosted tool is reachable |
| Salesforce login | Can you sign in to the org normally? | Whether authentication is broadly affected |
| Minimal API call | Try a lightweight endpoint such as /services/data/ or /services/data/v66.0/limits | Whether the API path works independently of a complex query |
| Error code | 401, 403, 404, 5xx, timeout, REQUEST_LIMIT_EXCEEDED, UNSUPPORTED_API_VERSION | Which troubleshooting branch to follow |
| Second client | Salesforce CLI, an existing integration, or another approved API client | Whether the failure is Workbench-specific |
Go to the official Salesforce Trust status site and search for the instance, domain, pod, or tenant relevant to your org. Salesforce incidents can be regional or instance-specific, so a green status for an unrelated instance does not prove that your org is healthy.
If Trust reports a service disruption, performance degradation, login problem, or maintenance affecting your environment, record the incident ID and time. Then avoid making speculative changes to connected apps, credentials, profiles, permission sets, network policies, or API versions unless the error specifically points to those settings. Configuration changes made during an outage can create a second problem after the platform recovers.
Workbench often passes Salesforce API error responses through with little interpretation. That is useful for troubleshooting: the exact HTTP status, Salesforce error code, endpoint, and message usually tell you more than a generic browser banner.
A timeout, 502, 503, or other 5xx response can be consistent with service degradation, overloaded infrastructure, or an intermediate network failure. Do not assume a 5xx proves a Salesforce-wide outage. Compare the same lightweight request from another approved client and check Trust. If multiple clients fail against the same Salesforce instance at the same time, the evidence points away from Workbench alone.
These generally point to authentication or session problems. Re-authenticate with OAuth instead of copying old session IDs between browsers. If normal Salesforce login also fails and Trust reports login impact, wait for service recovery before rotating credentials. If Salesforce login works but Workbench OAuth does not, investigate the Workbench connected-app path or use a supported alternative client.
A 403 usually means the request reached a service that refused it. Check user permissions, connected-app policy, IP restrictions, and the exact Salesforce error code. One known Workbench-specific example is OAUTH_APP_BLOCKED, which can occur when an administrator blocks the Workbench connected app. The Workbench project's connected-app guidance describes this scenario.
During a suspected outage, do not diagnose with a bulk load, metadata deployment, long SOQL query, or multi-step script. Start with a read-only endpoint that is cheap to execute. In REST Explorer, a request such as GET /services/data/ checks basic API reachability. A request such as GET /services/data/v66.0/limits can help you inspect organization limits when the API is functioning.
Salesforce documents Workbench REST Explorer as a way to call REST endpoints, but Workbench is not ideal for large or performance-intensive operations. The original Workbench documentation notes that browser and connection timeouts make it better suited to quick, on-the-fly API interactions than large data loads or exports.
REQUEST_LIMIT_EXCEEDED is not the same thing as a platform outage. Salesforce applies API request allocations, and when an org exceeds its rolling usage limit, further API calls can be blocked until usage falls below the threshold. Salesforce's July 2026 support article confirms that REST API, SOAP API, Bulk API, and Bulk API 2.0 calls all contribute to API consumption. See Salesforce guidance for REQUEST_LIMIT_EXCEEDED and its rolling API limit explanation.
If the error is a limit condition, repeated retries make the situation worse by consuming more calls when requests are still accepted. Identify high-volume integrations, pause nonessential jobs where operationally safe, and monitor usage in Salesforce Setup. Do not wait for a Trust incident to resolve a tenant-specific limit problem.
UNSUPPORTED_API_VERSION deserves its own branch. Salesforce published a May 2026 support article explaining that Workbench can default to a newer API version before a production or Developer Edition org supports it. The recommended Workbench fix is to lower the default API version to one supported by the target org. See Salesforce's UNSUPPORTED_API_VERSION troubleshooting article.
This matters during release windows because an API-version mismatch can look like an outage if you focus only on the timing. Verify the version error itself before waiting on platform recovery.
If the task is urgent and Workbench is the only component failing, reproduce the smallest request using Salesforce CLI or another supported, approved client. The purpose is diagnosis, not bypassing a genuine Salesforce outage. If both clients fail against the same org with comparable server-side errors, switching tools is unlikely to restore service. If CLI succeeds while Workbench fails, you have stronger evidence that the Workbench hosting, browser session, or connected-app path is the problem.
During a confirmed service disruption, aggressive manual retries rarely help. For automated clients, use bounded retries with exponential backoff and jitter where your integration design permits it. For manual Workbench use, wait for a meaningful status update or a reasonable interval before repeating the same request.
For write operations, be especially careful. A timeout does not always prove that Salesforce did nothing; the client may have lost the response after the server processed the request. Before resubmitting a create, update, delete, or deployment, verify whether the original action committed. Duplicate writes are often more damaging than a delayed retry.
| Symptom | Most useful next check | Avoid |
|---|---|---|
| Workbench page does not load | Check Workbench reachability and use another approved client | Changing Salesforce permissions immediately |
| OAuth redirects fail | Check Salesforce login, Trust, and connected-app policy | Sharing session IDs or credentials |
| REST Explorer returns 5xx | Check Trust and repeat a minimal read-only call from a second client | Running larger test jobs |
REQUEST_LIMIT_EXCEEDED | Review org API consumption and rolling limits | Rapid retries |
UNSUPPORTED_API_VERSION | Select an API version supported by the target org | Waiting for an outage that may not exist |
| Only one complex query times out | Simplify the query and inspect selectivity/volume | Assuming platform-wide downtime |
errorCode, and a short response excerpt.Never paste access tokens, passwords, session IDs, OAuth authorization codes, or full sensitive payloads into shared tickets or chat channels.
Switch away from Workbench when the failure is clearly isolated to Workbench, when the operation is too large for a browser-based utility, when you need repeatable scripted behavior, or when you require a supported development workflow. Salesforce's own replacement guidance specifically points developers toward Code Builder, Salesforce CLI, and the Salesforce Extensions for VS Code.
Do not switch tools merely to keep hammering an unavailable Salesforce service. A different client cannot fix a server-side outage, and repeated calls can make diagnosis noisier. During downtime, the best result is a clear classification: confirmed platform incident, Workbench-only failure, local network/browser issue, API-version mismatch, permission/authentication problem, API-limit exhaustion, or request-specific failure.
Salesforce Workbench errors are easier to handle when you treat them as signals, not diagnoses. Check Salesforce Trust, preserve the exact error, reduce the request, compare with one supported client, and follow the error code. That sequence helps you avoid unnecessary configuration changes during outages while also catching problems that look like downtime but are actually tenant-specific or Workbench-specific.
Review notable Salesforce outages in 2025, what failed, how long selected incidents lasted, and the practical resilience lessons teams can apply.
Build a practical Salesforce downtime continuity plan with impact analysis, RTO/RPO targets, manual workarounds, integration controls, and recovery checks.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Troubleshoot Salesforce Workbench login, REST Explorer, timeout, 503, API-version, and limit errors during downtime with a practical diagnostic checklist.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Understand the main causes of widespread cloud downtime, how failures cascade, what to check first, and how to design a more resilient recovery plan.
If Datorama or Marketing Cloud Intelligence seems down, use this evidence-based checklist to verify the outage, protect reporting quality, and know when data is trustworthy again.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
An AWS outage does not automatically mean Salesforce is down. Learn how Hyperforce, regions, instances, and Salesforce Trust determine whether your org is affected.
