Check Status Page

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.

Apr 24, 2026 · resolved Apr 24

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.

Apr 9, 2026 · resolved Apr 9

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.

Mar 3, 2026 · resolved Mar 3

All FedACH systems are operating normally again, as reported on the Fed's own status page here: https://www.frbservices.org/app/status/serviceStatus.do. We do not anticipate any further impact and all of our systems are operating normally. Marking this incident resolved.