Working with Salesforce timeouts well is mostly about designing within the limits rather than fighting them. The four-step routine covers: identify which timeout each operation is subject to, design the operation to fit within that timeout, monitor timeout occurrences in production, and refactor when timeouts become chronic. Each step is preventive engineering; the alternative is reacting to user-facing failures after they accumulate. Mature Salesforce production operations treat timeouts as architectural constraints to plan around, not bugs to work around.
- Identify the relevant timeout per operation
For each operation in your codebase or integration, identify which timeout applies. Synchronous Apex: 10-second CPU. Asynchronous Apex: 60-second CPU (Queueable, Future, Batch). HTTP Callout: 60-second per callout, 120 max. SOQL query: 120-second platform timeout. User session: configurable per profile, default 2 hours. Salesforce Connect external query: 120-second. Document the relevant timeout for each operation in the technical design document. Without this baseline, engineers troubleshoot timeouts without understanding the constraint.
- Design the operation to fit within the timeout
For Apex CPU-bound work, write bulk-safe code that operates on collections rather than single records. Move expensive work to asynchronous execution. Avoid deeply nested loops over large collections. For callouts, set explicit timeouts on every HttpRequest. Use Continuation for long-running synchronous callouts. For SOQL queries, filter by indexed fields, add LIMIT clauses, batch with Batch Apex. For sessions, pick the right timeout for the user audience: shorter for high-security profiles, longer for integration users. Document the timeout-fit decisions in the code or design doc.
- Monitor timeout occurrences in production
Configure Setup, Debug Logs, to capture timeout-relevant log levels for production users. For Event Monitoring-licensed orgs, query the API Performance Event log for slow API requests. Build a dashboard tracking timeout exception counts by class and operation. Set alerts on rising timeout counts; chronic timeouts are leading indicators of bigger problems. Without monitoring, timeouts hide in the noise until they cause customer-visible failures. Schedule a weekly review of timeout metrics in the production operations runbook.
- Refactor when timeouts become chronic
For timeouts that recur despite the design, refactor the operation. Move synchronous work to async. Add Custom Indexes through Salesforce Customer Support. Split large operations into smaller chunks. Replace inefficient SOQL with selective queries. For callouts to slow external services, add retry logic with exponential backoff rather than just longer timeouts. Document each refactor in the change history. For chronic timeouts that defy refactoring, consider whether the workload genuinely fits the Salesforce platform; some workloads belong on a dedicated compute platform with the Salesforce data accessed through APIs.
- Synchronous Apex has a 10-second CPU limit. Move long-running work to asynchronous (@future, Queueable, Batch) where the limit extends to 60 seconds.
- HTTP callouts in synchronous Apex are constrained by both the callout timeout and the overall 10-second CPU limit. Use Continuation when the external service is slow.
- SOQL queries on unindexed fields with LIKE filters can scan the entire object and hit the 120-second timeout. Add Custom Indexes or refactor the query.
- User session timeout interacts with MFA and the security review schedule. Shorter timeouts force more frequent re-authentication; balance security against user friction.
- Salesforce Connect external queries depend on the external system response time. Slow external systems hit the 120-second timeout; consider Data Replication instead for genuinely slow sources.