Verified September 16, 2026. Workbench errors are easy to misread during a Salesforce incident. A failed login may come from an expired session, a wrong environment, a broken Workbench route, or a Salesforce API outage. A request that returns 503 Service Unavailable points in a different direction from a 401 Invalid Session, even though both can appear when a developer is trying to work quickly.
The goal of troubleshooting is not to force one request through. It is to identify which layer is failing, protect data while the system is unstable, and know when the evidence is strong enough to wait, switch tools, or contact the right support channel.
| What you see | Most likely layer | Best next move |
|---|---|---|
| Workbench page will not load | Workbench site, browser, DNS, or network path | Open Salesforce Trust Status and test the site from a permitted alternate network. |
| Workbench loads, but login fails with 401 | Session, OAuth, username, password, or login flow | Start a fresh authorized login and confirm the selected environment. |
| API request returns 403 | Permissions, connected-app policy, or API limit | Check the user, connected app, and request limits; do not treat it as proof of downtime. |
| Several API calls return 500, 502, or 503 | Salesforce platform, edge routing, maintenance, or overload | Compare the error time with your instance and product status on Trust. |
| Only one query or object fails | Request syntax, object access, record sharing, or data issue | Reduce the request to a harmless, known-good read and inspect the response body. |
This table is a starting point, not a diagnosis. The same HTTP code can have different causes depending on the endpoint, authentication method, and organization policy.
Workbench is a browser-based suite for interacting with Salesforce organizations through several APIs, including REST, SOAP, Bulk, Streaming, Metadata, and Apex-related tools. However, the Workbench site states that it is not an official Salesforce product and that Salesforce support is not available for Workbench itself. Its About page also warns users not to use the application with production data.
That warning changes how you should respond during downtime. Salesforce Support can investigate a Salesforce service, instance, or API problem, but it may not troubleshoot every Workbench interface behavior. Conversely, an issue reported only by Workbench may belong to Workbench or to the browser path rather than the Salesforce platform.
Keep the troubleshooting read-only whenever possible. Do not paste passwords, OAuth secrets, session IDs, access tokens, customer records, or unredacted request headers into screenshots, chat messages, or public issue reports.
Open Salesforce Trust Status in a separate tab. Salesforce’s help documentation directs customers to this page for product outages and service degradation, and the Trust site can show information for products as well as specific instances.
Check two views:
An instance marked Available is not a guarantee that every API operation will work. It means the instance and its services are available according to Salesforce’s status definition. Performance Degradation suggests access may work with latency or partial functionality; Service Disruption means the instance is unavailable; Maintenance indicates a maintenance event that may or may not affect access.
Workbench can connect to different Salesforce environments. Before concluding that an API is down, confirm whether the failing request targets production, a sandbox, or another authorized environment. A test that succeeds in one environment does not clear the environment that is actually failing.
Use the My Domain or instance identifier for the affected org. Salesforce documents that the My Domain prefix can be used in Trust Status, while an administrator can find the instance in Setup under Company Information. Write down the instance, environment, API version, approximate failure time, and endpoint. This small record prevents a common mistake: comparing a production error with a healthy sandbox status.
If the Workbench login page itself shows an unsupported login method or loops back to the login screen, treat that as a separate authentication or Workbench issue until Trust Status and a direct Salesforce login indicate otherwise. Do not repeatedly submit credentials during a suspected outage; excessive retries can create lockouts or add noise to the investigation.
Salesforce’s REST API documentation explains that the response header contains an HTTP status code and that the body usually contains a message and, when relevant, the field or object associated with the error. Preserve both pieces of evidence.
| Code | Salesforce’s documented clue | How to interpret it during downtime |
|---|---|---|
| 400 | The request could not be understood, often because the JSON or XML body is invalid. | Usually fix the request before treating it as an outage. |
| 401 | The session ID or OAuth token is expired or invalid. | Re-authenticate through an approved flow; a 401 alone is not evidence of a platform outage. |
| 403 | The request was refused, often because of permissions or an API limit. | Check access and limits before escalating to an availability incident. |
| 500 | An error occurred within the Lightning Platform. | Retry only after recording the response; compare repeated failures with Trust Status. |
| 502 | Salesforce Edge could not communicate successfully with the instance. | A routing or platform-side problem is possible, especially across multiple requests. |
| 503 | The server is unavailable; maintenance or overload may be involved. | Check for an incident or maintenance event and avoid destructive retries. |
Once you know the status and environment, use the smallest permitted read-only test. A good comparison has three properties: it targets the affected org, it does not modify data, and it is simple enough that a request-format mistake is unlikely.
Do not use a write, delete, bulk update, metadata deployment, or migration request as a health check. During an incident, a write can create partial results, duplicate work, or a false impression that recovery has occurred.
Stop redesigning the query unless you have independent evidence that the request is malformed. Save the incident number, affected service, instance, start time, and latest update. Follow Salesforce’s recovery messages and protect queued work from duplicate retries.
Focus on Workbench, browser, network, authentication, or local policy. Try a private browser window, a supported alternate browser, and a permitted network comparison. The Workbench site directs Workbench-specific support to its open-source community resources, while Salesforce Help remains the route for Salesforce product and account support.
Move to identity and authorization analysis. Confirm the user, connected app policy, OAuth scope, session age, API access, profile or permission set, and organization limits. Repeatedly refreshing the browser will not repair a missing permission or an invalid token.
Investigate the endpoint, object, field, record sharing, API version, request body, and response body. A narrow failure is not enough to label Salesforce down globally. Reduce the request until you can identify whether the problem is syntax, access, data, or a dependent service.
If the Salesforce issue persists, use the official Salesforce Support guidance for the channel available under your Success Plan. Include:
Remove credentials, session IDs, access tokens, customer names, record IDs, and sensitive payloads before sending logs. If the problem is only Workbench, use the support route identified on the Workbench Help page; Salesforce does not provide product support for Workbench itself.
A green status indicator is encouraging, but it is not the finish line. Verify recovery in layers:
The result you want is not simply “the page opened.” You want the original authorized operation to succeed, with the expected response and no unreviewed side effects.
For Salesforce Workbench errors during downtime, begin with Trust Status and the affected instance, then classify the HTTP response before changing credentials or rewriting requests. A repeated 500, 502, or 503 across simple read-only tests and a matching Trust incident supports a Salesforce-side explanation. A 401, 403, 400, or Workbench-only failure usually calls for authentication, permissions, request, browser, or Workbench troubleshooting instead. Because Workbench is not a Salesforce-supported product, keep production data out of it, document the boundary clearly, and use the latest official status and support guidance when the evidence changes.
Compare document, spreadsheet, and layout behavior in ONLYOFFICE Docs and Microsoft 365 web apps, then use a quick test to choose the safer editor for your files.
Trace formula mismatches to syntax, regional separators, recalculation, date systems, or unsupported functions, then verify the workbook before sharing it.
See what recent release data can—and cannot—prove, then compare both office suites on the same files and computer.
Compare exact matches, left-side lookups, missing-value handling, and version support so you can choose a reliable Calc formula.
Learn how Writer page styles and Word section links affect cover pages, Roman numerals, and numbering restarts when you move a document.
You've just nailed a great product demo. The energy was right, you handled objections like a pro and you could see the lightbulb moment on your prospect's face. The Zoom call is over, you click “End Recording,” and you feel great.
Compare Pardus Software Center with APT commands to find, install, remove, and update packages using the method that fits your task.
See what Pardus’s published RAM requirements mean, then compare XFCE and GNOME on the same PC with repeatable MemAvailable readings.
See where HamoniKR 8.0 fits in a business desktop plan, what its Korean-focused features support, and what to verify before a wider rollout.
Understand how Gooroom’s boot verification and runtime protections fit together, what “sandbox” means, and which settings you should verify on your device.
