An org can have 10 synchronous Apex requests running longer than 5 seconds at the same time. The eleventh is rejected. The limit is org-wide, not per user, so one slow page opened by twenty people takes the whole org down for everyone including the people who never touched it.
What counts
The clock starts when the request begins executing and counts only time spent in the Salesforce application server. Once a single request passes 5 seconds of that, it occupies one of the 10 concurrency slots until it finishes.
Time spent waiting on a callout to an external system does not count towards the 5 seconds. Neither does time spent in the database. Long database operations and long callouts have their own constraints, so a 30 second callout is a problem for other reasons, just not this one.
The limit applies to synchronous Apex: Visualforce controllers, Lightning and Aura server-side actions, Apex REST and SOAP endpoints, and the execute anonymous window. Batch, queueable, scheduled and future jobs run asynchronously and do not occupy these slots.
The symptom
Users see an error saying the concurrent request limit has been exceeded, or a page that simply will not load. It hits everybody at once, across unrelated parts of the org, which is what makes diagnosis confusing. Someone reports that the Cases tab is broken while somebody else reports the same thing about a completely different custom page.
The tell is that nothing changed in the broken area. Look instead for what changed anywhere, or for what got busier.
Why it cascades
This is the part worth understanding. A slow request holds a slot. While slots are scarce, requests queue and take longer. Users whose page did not respond hit refresh, which issues another request while the first one is still running. Now there are two slow requests per user instead of one.
The org does not degrade gently. It goes from fine to unusable over roughly a minute, because the retry behaviour of frustrated users is itself the amplifier.
Finding the culprit
Event Monitoring, if you have it, gives you the ApexExecution and the concurrent long-running request events directly, with the entry point and the duration. That is the fast route.
Without it, work from the Setup Debug Logs and from timing:
- Set a trace flag on a user who reproduces it and look for requests over 5 seconds of CPU.
- Check what runs on page load for the roles that reported the problem. An Aura or LWC controller method that queries a large object without a selective filter is the usual answer.
- Look for recently deployed controllers, and for reports or list views embedded in a page.
- Check whether a scheduled integration writes at the same time, since trigger work on a big load lands on the synchronous side.
The most common real cause is a non-selective query in a controller that was fine when the object had 50,000 rows and is not fine at 5 million.
Fixes, roughly in order of usefulness
Make the query selective. Run it through the Query Plan tool. A TableScan leading operation on a large object is the finding. An index or a better filter usually takes a 12 second request under one second.
Move work off the page load. A component that does heavy work before rendering can often render immediately and fetch on demand, or behind a button. The user perceives it as faster and the org stops holding slots.
Make it asynchronous. Anything the user does not need an answer to right now belongs in a queueable. Async has a 60,000ms CPU ceiling rather than 10,000ms, and occupies no synchronous slot.
Cache what does not change. Describe results, configuration records and reference data can go in a static within the transaction or Platform Cache across transactions. A controller re-reading the same setup records on every request is pure waste.
Prevention
Put a timing assertion on the controller methods that run on page load, and instrument them with Limits.getCpuTime() so the number appears in the log. Anything approaching 5 seconds in a sandbox with production-shaped data is a production incident waiting for enough concurrent users.
Frequently asked
Is the limit per user or per org? Per org. That is precisely why it is dangerous.
Do API calls count? Synchronous Apex invoked through the API does, including Apex REST endpoints and execute anonymous.
Can the limit be raised? No. It is a platform protection, not a configurable setting.
Does a slow report cause it? Reports run outside Apex and are governed separately, so a slow report does not consume these slots. A report embedded in a page whose controller also runs Apex can still contribute to the perceived outage.
