Check Status Page

Jun 22, 2026 · resolved Jun 22

Between approximately 19:11 and 19:23 UTC, a subset of Check API requests returned 5xx errors, which also intermittently impacted Console and Components. The errors occurred because a routine deployment introduced a new data value that application instances still running the previous version did not yet recognize; while the rollout was in progress, requests served by those older instances failed. Error rates returned to normal at 19:23 UTC once the deployment fully completed and all traffic was handled by the updated version. We are implementing safeguards, including updated data-migration and deployment practices plus additional automated review checks, to prevent similar issues in the future. No customer action is required, and the issue did not affect payment or payroll processing.

Jun 18, 2026 · resolved Jun 18

All instant payments scheduled for today have been successfully processed. If we have not contacted you via Slack or email, all your customers' employees were paid today.

Jun 6, 2026 · resolved Jun 7

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.

May 27, 2026 · resolved May 27

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.

Apr 28, 2026 · resolved Apr 28

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.

Is Check down right now?

No — Check is up. All systems operational as of Jul 13, 11:47 PM UTC.

What is Check's current status?

Check: All Systems Operational. Alert24 checks Check's status page continuously and can notify you the moment it changes.

How do I get alerted when Check goes down?

Alert24 monitors Check and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.