Issues with webhook ingestion, GraphQL queries

What to do

• Check whether your product depends on Buildkite. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 42m it lasted.

  Anything that failed between 2026-09-22 20:07 UTC and 2026-09-22 20:50 UTC may need a replay.

• Subscribe to Buildkite's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=buildkite works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Root cause

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

Updates from Buildkite 4

1. investigatingSep 22, 2026, 8:07 PM UTC

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

   provider

2. identifiedSep 22, 2026, 8:26 PM UTC

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

   provider

3. resolvedSep 22, 2026, 8:50 PM UTC

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

   provider

4. postmortemSep 28, 2026, 4: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.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.