Issues with webhook ingestion, GraphQL queries

Update timeline

1. investigating Sep 22, 2026, 08:07 PM UTC

   We're seeing an issue affecting webhook ingestion and execution of GraphQL queries and are investigating the cause.

2. identified Sep 22, 2026, 08:26 PM UTC

   Our engineers have addressed the issue and we're monitoring recovery.

3. resolved Sep 22, 2026, 08:50 PM UTC

   Services are fully recovered. Webhook ingestion was affected between 19:09 UTC - 19:32 UTC.

4. postmortem Sep 28, 2026, 04:12 AM UTC

   ## Service Impact On September 22, 2026, between 19:09 and 19:32 UTC, customers experienced failures ingesting webhooks and executing GraphQL queries. Some web application requests also failed or timed out. During this period, 2.0% of requests to our webhook ingestion endpoints and 20.3% of requests to our external GraphQL endpoint returned HTTP 500 errors. Webhook ingestion errors ceased by 19:30 UTC, and external GraphQL errors returned to background levels by 19:32 UTC. ## Incident Summary While investigating a separate API performance issue, we made a manual configuration change intended to rollback a routing change for one database proxy. The command instead changed the routing configuration for another database proxy, disrupting access to a database shard used internally by Buildkite. Some customer-facing operations search across all database shards to locate their shard, where routing information isn't available in the request. Those requests round robin through available shards, and could encounter the unavailable shard and wait for a database connection to time out. This extended the impact beyond our internal workloads. We reverted the incorrect configuration and verified that the database proxy had healthy endpoints and load-balancer targets. Two contributing factors allowed the change to cause an outage: the command was not independently checked before execution, and our infrastructure accepted a Service configuration that selected the wrong database proxy workload. The cross-shard lookup behaviour then allowed the disruption to affect requests for other customers. This configuration-change outage was separate from the API performance issue we were originally investigating. ## Changes we're making * Safer operational procedures: We have updated our runbook and introduced an explicit second person review requirement for manual production commands. * Automated safeguards: We’ve added validation to prevent database proxy routing changes from selecting the wrong workload. * Improved failure isolation: We’ve been working on an ongoing initiative to make database shard discovery more resilient, eliminating the remaining cases where an unavailable shard may impact requests for other customers.