Jobvite Operational Status Page

Jun 18, 2026 · resolved Jun 18

Following our investigation, we determined that this was an isolated incident and not indicative of a widespread service disruption. The affected customer's issue has been addressed and we have observed normal service operation. No further customer impact has been identified.

Jun 11, 2026 · resolved Jun 11

**Incident Summary** Beginning approximately June 5, 2026, and escalating on June 11, 2026, Jobvite experienced a degradation in outbound email and notification delivery. The incident resulted in intermittent delays \(ranging from 30 minutes to several hours\) or total delivery failure for various system-generated communications. Affected services included: * **Interview Scheduling:** Google Calendar invites and candidate communications. * **Hiring Workflows:** Evaluation forms, requisition approvals, and workflow notifications. * **Offers:** Offer letters to candidates and CC'd offer notifications for recruiters. **Detection** The issue was identified through a sharp increase in customer support reports. The first isolated instance was noted on June 5, and widespread escalation was confirmed on June 11 at 3:52 PM ET. Internal investigations confirmed that no automated alerts had been triggered because the system was "silently" failing. **Root Cause** The issue was caused by a temporary shortage of available server capacity in the external cloud market. This triggered an automated system error that inadvertently deactivated healthy servers while trying to find new ones. As a result, our email delivery system was forced to run on a single server, which became overwhelmed by the volume. This caused outgoing messages to be diverted into a backlog rather than being sent to their intended recipients. **Resolution** Technical teams manually intervened on June 11 to restore service: * **Capacity Restoration:** Engineers manually unpaused the affected servers and stabilized the server fleet to ensure adequate processing power. * **Queue Reprocessing:** At 5:03 PM ET, teams began reprocessing the 60,000 backlogged messages. * **Recovery:** By 2:30 PM ET, all mail queues were drained, and normal delivery speeds were restored. * **Note:** Not all affected emails were ultimately delivered. Some messages were lost before they entered the mail queues and therefore could not be reprocessed. For those cases, related alerts were logged in the in-app notification bell icon. If a customer reports that an expected email was not delivered, advise them to check the in-app notification bell for the corresponding alert or notification. **Preventative Measures** To prevent a recurrence of this issue, the following actions are being implemented: * **Enhanced Monitoring:** New proactive alerts are being added to notify engineering teams immediately if the server count drops below required levels or if mail queues begin to back up. * **Infrastructure Stability:** We are adjusting our server configuration to guarantee a minimum number of "always-on" servers that cannot be paused by automated scaling logic, ensuring baseline capacity is always available. * **Automated Recovery:** We are developing automated tools to quickly reprocess backlogged messages without requiring manual intervention. * **Process Improvement:** A formal technical runbook has been created to help on-call engineers diagnose and resolve similar cloud-market availability issues more rapidly.

Jun 8, 2026 · resolved Jun 9

**Incident Summary** Between approximately June 3 and June 9, 2026, analytics dashboards did not reflect recent changes made in the ATS \(for example, candidate status updates\). All underlying data remained intact and accurate in the system of record — dashboards were delayed, not incorrect — and no data was lost.  **Detection** The issue was identified on **June 8, 2026, at 10:14 AM EDT**, following customer reports that analytics data was not updating. Although internal monitoring systems exist, they were hosted on the same server that failed, which prevented alerts from firing when the server went offline.  **Root Cause** The server responsible for syncing ATS data into the analytics platform was automatically replaced following routine infrastructure health events. Configuration issues prevented the replacement server from running the data sync process correctly, and existing monitoring did not detect the gap because it runs on the same server it monitors.  **Resolution** Once identified, our engineering team restored the server's sync capability, deployed the correct version of the sync software, and re-ran the data sync. Analytics dashboards were fully up to date by the morning of June 9. No action is required from customers, and no data was lost.  **Preventative Measures** To prevent recurrence, we are implementing the following improvements: * Fixing the server configuration so that a replaced server is fully functional automatically, without manual steps * Fixing the code deployment process so that the current version of the sync software is always deployed on a replaced server * Moving sync health monitoring to an independent system so that alerts fire even if the ETL server itself is unavailable * Formally documenting and agreeing on a complete recovery checklist across the data engineering team

May 29, 2026 · resolved Jun 1

We want to share an update on a recent automation issue, including what happened, how it was resolved, and the steps we’ve taken to prevent it from happening again. ## Customer Impact Between May 27 and May 29, 2026, a subset of open job postings did not appear in search results on affected career sites. While all postings remained live within our system and no jobs or applications were lost, reduced visibility in search may have led to fewer candidate applications during this period. ## Root Cause The issue was caused by an internal search indexing component that became temporarily unavailable following routine infrastructure scaling. As a result, updates to certain job postings were not written to the search index, preventing them from appearing in search results. ## Resolution Once identified, our engineering team restored the affected indexing component and re-processed all impacted job postings. This fully restored search result accuracy. No action was required from customers at any point. ## Preventative Actions To prevent recurrence, we are implementing the following improvements: * Enhancing monitoring to directly surface indexing write failures in real time * Adding automated job-count reconciliation alerts to quickly detect discrepancies * Enabling automatic recovery for the search indexing component * Strengthening and hardening the re-indexing process for faster remediation

May 26, 2026 · resolved May 26

**Incident Summary** Between May 21 and May 26, 2026, analytics dashboards did not reflect recent changes made in the Jobvite ATS — for example, candidate status updates appeared outdated. All underlying data remained intact and accurate in the system of record throughout this period. Dashboards were delayed, not incorrect, and no data was lost.  **Detection** The issue was identified on May 26, 2026 after customers reported that analytics dashboards were not reflecting recent ATS activity. Upon receiving these reports, our engineering team immediately began investigating.  **Root Cause** The server responsible for syncing Jobvite ATS data to the analytics platform was automatically replaced by our cloud infrastructure provider following a routine health event on May 21. A configuration error prevented the replacement server from initializing the data sync process. Because the server remained reachable at the network level, automated health checks did not flag it as unhealthy, and the sync disruption was not detected by internal monitoring during this window.  **Resolution** Once identified, our engineering team corrected the server configuration, rebuilt the server, and re-ran the full data sync. Analytics dashboards were fully up to date the same day \(May 26\). No action was required from customers, and no data was lost.  **Preventative Measures** To prevent recurrence, we are implementing the following improvements: * **Data-freshness monitoring** — Adding alerting so that any delay in analytics updates is detected within minutes, rather than relying on network-level health checks alone. * **Server build hardening** — Strengthening the server provisioning process so that replacement servers are fully functional and verified automatically, without manual intervention. * **Recovery documentation** — Formalizing and streamlining the recovery runbook to further reduce time to resolution in the event of a future issue.