JazzHR experienced a minor incident on June 9, 2026 affecting API and Application, lasting 4h 46m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- identified Jun 09, 2026, 01:07 PM UTC
We are currently investigating ongoing service degradation affecting the JazzHR platform. Customers may experience intermittent 500 Internal Server Errors, slow application performance, API instability, and issues loading billing-related profile information. Our engineers have identified the problem and are working towards a resolution. We will provide a status update by 11 am ET.
- monitoring Jun 09, 2026, 02:30 PM UTC
We have put in place a fix and are seeing initial positive recovery, we will continue monitoring to insure this incident is fully resolved.
- resolved Jun 09, 2026, 05:54 PM UTC
This incident has been resolved. Incident Duration: June 8, 2026, 3:18 PM ET – June 9, 2026, 9:30 AM ET Service recovery began ~9:30 AM ET; full resolution confirmed and posted ~10:30 AM ET after a period of monitoring.) Impact Summary: During this window, some users may have experienced errors or been unable to access parts of the application. Cause: An internal issue affected a system that supports billing and subscription information. Because this system is used across the product, the disruption led to elevated errors and degraded access throughout the application. Mitigation: The issue has been resolved and service has returned to normal. We are putting additional safeguards in place and do not expect it to recur. A full root cause analysis will be posted within 7–10 business days. An RCA will be provided within 7-10 business days if applicable.
- postmortem Jun 12, 2026, 01:31 PM UTC
**Incident Summary** On June 8–9, 2026, some users experienced errors or were unable to access parts of the application for a period of approximately 18 hours. Because the affected component supports billing and subscription information used across the product, the disruption affected general application access, not only billing pages. No customer data was lost. **Detection** The issue was identified by internal engineering teams at approximately **4:18 PM ET on June 8**, following a significant rise in application errors and reports from Customer Support. While the symptoms were detected within an hour of the initial impact, the underlying cause required extensive investigation as it involved a silent failure of an internal component. **Root Cause** An internal issue caused the application to lose access to cached billing and subscription data, which led it to generate an unusually high volume of requests to a third-party service we rely on. That volume exceeded the service's allowed limits, and requests were temporarily blocked, producing widespread errors. **Resolution** Our engineering team corrected the underlying issue, significantly reduced the volume of requests to the third-party service, and restored normal operation. Service recovered by **9:30 AM ET on June 9**, and we verified the application was operating normally. **Preventative Measures** To prevent recurrence, we are implementing the following improvements: * Preventing the internal cache from disabling itself on transient errors, and alerting immediately if it does * Reusing authenticated sessions and applying limits earlier in the request path to avoid generating excessive third-party traffic * Maintaining safe headroom under third-party limits and adding monitoring so this condition is detected within minutes