checked Sep 7, 2026 5:12 PM UTC · Lever's official status page
Lever is up and running.
All components operational
Statusfield watches Lever alongside the rest of your stack and tells you when its status changes. Email, Slack, Microsoft Teams, PagerDuty, and webhooks.
Email only. No password. Free.
4 reports published by Lever in the last 30 days
When Lever breaks, it is typically resolved in 6h — median across 4 resolved incidents over 90 days.
resolvedAug 25 · 08:30 UTC
At about 8:30am UTC on 8/25/2026 a scheduled server rotation at https://hire.eulever.co/ caused increased latency and some failed page loads until 9:15am UTC. Impacted users would notice a "504 error" during the affected page loads. Service was restored to all users as of 9:15am UTC on 8/25/2026. An full RCA will be posted to this issue within 7 to 10 business days.
Reported by Lever on their status page.
resolvedAug 24 · 14:16 UTC
Status: Resolved Our monitoring has confirmed that there are no further issues related to this incident. Service has remained stable, and the incident is now considered resolved. A Root Cause Analysis (RCA) will be provided within 7-10 business days.
Reported by Lever on their status page.
postmortemAug 14 · 18:26 UTC
**Incident Summary** On August 12, 2026, between approximately 10:31 AM and 10:45 AM PDT, the Lever platform experienced partial unavailability. During this 14-minute window, some customers were unable to access the platform, and others experienced elevated error rates for API requests. **Detection** The issue was identified through internal monitoring. A Datadog alert for high database page faults triggered at 10:37 AM PDT, notifying the engineering team. This allowed responders to isolate the specific database nodes experiencing high load and identify the responsible operations. **Root Cause** The incident was triggered by a safety mechanism within an internal administrative tool designed to prevent expensive database queries. When an operator searched for unindexed data, this safety check requested a "plan" from the database to see if the query was safe to run. However, because the data was unindexed, the database attempted to evaluate every possible retrieval method, resulting in the same large account being scanned 11 times for a single request. These diagnostic checks bypassed standard time limits, consuming the database read capacity required for normal customer traffic. **Resolution** Engineering teams identified and terminated the long-running diagnostic operations, which immediately restored database performance and platform stability. Following the cleanup, a database-level safeguard was applied to force these specific queries into a single, efficient path, preventing the database from attempting multiple expensive scans in the future. **Preventative Measures** * **Redesigning Safety Checks:** We are replacing the current diagnostic method with a new system that verifies query safety by inspecting database definitions directly, eliminating the need to run expensive tests on live data. * **Advanced Alerting**: We are implementing new monitoring for database read churn and long-running operations to detect and resolve similar issues before they affect customers. * **Enhanced Logging:** We are improving internal audit logs to ensure faster identification and attribution of administrative database activity. * Database Optimization: We are adding new indexes to properly support these search patterns, ensuring they are inherently efficient.
Reported by Lever on their status page.
postmortemAug 14 · 18:16 UTC
**Incident Summary** On August 7, 2026, between approximately 6:00 AM and 5:30 PM ET, some customers were unable to send offer letters, and some document and resume previews failed to generate. Files uploaded successfully; only the step that converts them into a viewable PDF or preview failed. No data was lost. **Detection** Identified on August 7 at approximately 11:47 AM ET following customer reports to our Support team. **Root Cause** A third-party service we use to convert documents into PDFs experienced an outage lasting most of the day. During it, the service accepted conversion requests but never completed them. Our system is designed to switch to a backup conversion method when that service reports a failure — but because these requests neither succeeded nor failed, they simply waited, and the backup was never used. Each waiting request also occupied one of a limited number of conversion slots, so delays spread to other documents. **Resolution** We added a strict overall time limit to document conversions: if the third-party service does not finish within that window, we stop waiting and convert the document using our own backup method instead. We also corrected a related defect that had prevented the backup from being used reliably. Both fixes were released to production on the afternoon of August 7, while the third-party outage was still ongoing, and conversion success rates returned to normal levels the following day. We then re-processed the documents that had failed to convert during the outage. **Preventative Measures** · We fixed a defect that had prevented this service's health measurements from reaching our monitoring system and are adding alerts on the document conversion failure rate, so issues like this are detected automatically and quickly, rather than through customer reports. · The new time limit can be adjusted without a code release, and we are documenting a procedure to route all conversions away from the third-party service during a vendor outage.
Reported by Lever on their status page.
