A fix has been deployed and webhook delivery times are back under 800 ms across all EU consumers. We're watching the queue depth before we call this resolved.
The delay traces back to a backlogged retry queue on one of our EU webhook workers. We've scaled out additional workers and are draining the backlog now.
We're investigating reports of delayed webhook deliveries for customers in the EU region. API requests, the Dashboard, and the CDN are unaffected.
We'll promote a read replica and upgrade Postgres to 16.4 in us-east-1. Expect up to two brief connection resets (< 5 s each). Reads and writes recover automatically; no action needed on your side.
Window: Jul 6, 09:00–10:00 UTC · 02:00–03:00 PT
We're moving static asset caching to a new edge provider for faster cold reads in APAC. Cache-control behavior is unchanged; you may see one-time cache misses as the new edges warm up.
Window: Jul 14, 22:00–23:30 UTC · 15:00–16:30 PT
A bad config push removed a connection-pool limit and saturated the primary database. We rolled back the change and added a guardrail to the deploy pipeline.
Root cause identified as a configuration change to the API gateway. Rolling back now.
We're seeing a spike in 503 responses on the API and are investigating.
A slow query in the analytics panel was caching incorrectly and pegging a worker pool. We shipped a query fix and the Dashboard is fully responsive again.
Performance is recovering after we restarted the affected worker pool. Watching latency.
Some users report the Dashboard taking 5–10 s to load. The API itself is unaffected. Investigating.
Database upgrade finished ahead of schedule with two brief connection resets, exactly as announced. No data was affected.
Maintenance has started. The Database component is in a maintenance state during the upgrade window.
Subscribe to receive an email the moment we open or resolve an incident, plus a heads-up before scheduled maintenance.