Is Check down?

We are investigating an issue impacting payroll preview and approval. Requests to preview or approve payrolls are returning errors. This affects all payroll types. Other endpoints are not impacted. Our team has identified a database capacity issue as the root cause and is implementing a permanent fix. Estimated time to resolution: within 90 minutes.

Update: We have confirmed the root cause and are now applying a database fix. We are rolling the change through sandbox first before applying to production. Due to the size of the change, we are revising our estimated time to resolution to several hours. We will continue to provide updates as the fix progresses. Payroll preview and approval remain impacted across all payroll types in production. These endpoints will be unavailable in sandbox during application of our database fix. Other endpoints are not affected.

Update: The database fix has been successfully applied to our sandbox environment. The fix is now in progress on production. Estimated time to resolution: 60-90 minutes. We will update when complete. Payroll preview and approval remain impacted in production. Sandbox payroll operations have been restored.

Update: The database fix has been successfully applied to production. Payroll preview and approval are now operational and we are no longer seeing errors. We will continue monitoring to confirm stability before fully resolving this incident.

Resolved: The database fix has been fully applied and verified. Payroll preview and approval are operating normally across all environments. This incident has been resolved. Root cause: A database limit was reached that prevented payroll calculations from being processed. We have applied a permanent fix and are adding monitoring to prevent recurrence. We apologize for the disruption and thank you for your patience.

On the evening of Tuesday, May 26, 2026, a code change caused a subset of API key requests to incorrectly return 403 Forbidden. We detected the issue after a partner report, reverted the change, and restored service within approximately 5 hours. We are deeply sorry for the disruption. This explains what happened and what we are doing to prevent recurrence. Impact The issue was live from Tuesday, May 26 at 8:04 PM ET to Wednesday, May 27 at 1:27 AM ET, a window of 5 hours and 23 minutes. During that time, API requests that create or update resources (POST and PATCH) returned 403 Forbidden for a subset of partners: partners who had their API key associated with a Console user of the roles standard or cost owner. Most partners were not affected. Read traffic (GET) and the underlying data were not affected; no records were created, modified, or lost as a result of this bug, and approved payrolls and scheduled payments continued to process normally. Root cause We deployed an authorization refactoring on our write endpoints. The change contained a bug that caused the new check to incorrectly reject legitimate write requests for some partners if their API key was tied to a Console user with a role of either standard or cost owner. These unintended errors were mixed with legitimately rejected traffic, which affected our detection time. The change was reverted. No further action is required from partners, and any request that failed with a 403 during the window can be viewed in API Logs and safely retried. What we are doing differently First, we will reintroduce the change behind a safer rollout, re-landing the additional write-path authorization check with additional automated tests for this API key provisioning setup and in more incremental stages. Second, we will tighten our deploy guardrails by restricting changes affecting authentication or authorization to adjusted hours, along with implementing more robust post-deploy monitoring for faster response. If you believe you saw a related issue outside the window above, or have questions about this incident, please reach out to us and reference this note.

We've identified an event impacting AVI availability and performance inconsistency. Investigation in progress.

The system is recovering. We are actively monitoring to ensure it remains recovered. Root cause analysis to follow.

4/28 — Resolution Update and RCA Impact and duration: From approximately 1:05 AM PT to 1:44 AM PT on Tuesday, April 28 (~40 minutes), API endpoints across the platform returned elevated error rates and Console pages were intermittently unavailable. Health checks returned to green at 1:44 AM PT and the system has been stable since. What happened: Two scheduled background jobs ran simultaneously in the early-morning window and pushed our cache layer past its memory limit. Once the cache filled, normal cache writes began failing globally, which surfaced as the broad API degradation. Today's root cause is distinct from the SEV-2 on Friday, 4/24, which was driven by an inbound webhook volume spike from a banking partner. We traced today's failures directly to cache memory pressure, not webhook volume. Going forward: We are taking immediate steps to prevent recurrence, including reducing the load these scheduled jobs place on the cache layer and improving how the system handles cache pressure so it degrades gracefully rather than producing errors. We are also strengthening monitoring on cache health and related signals so this class of issue is caught before it impacts API availability.

We identified spikes in API latency and errors. Investigation in progress.

System is recovering. We are still investigating this issue to understand root cause and therefore prevent recurrence, as well as assessing potential impact.

This issue has been resolved. This morning Check experienced a database overload from increased webhook traffic that spiked for a a period of time on the morning of 4/24, and surfaced as high latency and error count. The team identified the issue, resolved the immediate database load concerns and restored functionality. The Check engineering team will be following up promptly with a resolution to prevent recurrence.

We are currently investigating this issue with the highest levels of urgency.

We are continuing to investigate this issue.

A fix has been implemented and we are actively monitoring our systems.

We identified and resolved the cause of elevated latency and degraded performance. A newly enabled internal process for synchronizing tax filing data generated significantly higher database load than expected, impacting API response times from ~9:15am - 9:38am ET. The feature flag has been reverted and system performance has returned to normal.