An unavailable application replica caused intermittent delays of approximately five seconds on affected requests. This impacted dashboard loading, authentication checks, and API traffic. Dashboard visits could experience longer delays when several affected requests occurred in sequence.

We restarted the production database to apply a memory configuration change. The database was unavailable for about 7 seconds. During the following two minutes, roughly a quarter of gateway requests received HTTP 502 while application connections re-established. Requests during that window can be safely retried. No data was lost, and no other services were affected.

The Overview and Provider Usage pages of the dashboard intermittently failed to load for a subset of workspaces, with a peak between 14:33 and 14:46 UTC on July 21. The core API was not affected: request routing, ingestion, and analytics data recording continued normally throughout, and no data was lost.

Root cause: a recent release changed two analytics queries in a way that bypassed their database index. On large workspaces these queries fell back to heavy scans whose memory allocations failed under load on the database host, returning errors to the dashboard.

Resolution: we deployed new database indexes matching the updated queries and removed the failing allocation path. Dashboards have been fully operational since 14:46 UTC. We are also adding headroom on the database host to prevent this class of issue as usage grows.