Skip to main content
Buildkite logo

Is Buildkite Down?

No — Buildkite is up

Reachable from all 8 checked regions

Average response time: 359ms

Last checked · checks run every 6 hours

Official status page: https://www.buildkitestatus.com

Buildkite uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
202ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 26 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

26-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: 100.00% uptime, 24 checks
Aug 27: 100.00% uptime, 32 checks
Aug 28: 100.00% uptime, 32 checks
Aug 29: 100.00% uptime, 32 checks
Aug 30: 100.00% uptime, 31 checks
Aug 31: 100.00% uptime, 32 checks
Sep 1: 100.00% uptime, 32 checks
Sep 2: 100.00% uptime, 31 checks
Sep 3: 100.00% uptime, 32 checks
Sep 4: 100.00% uptime, 24 checks
Sep 5: 100.00% uptime, 29 checks
Sep 6: 100.00% uptime, 28 checks
Sep 7: 100.00% uptime, 31 checks
Sep 8: 100.00% uptime, 16 checks
Sep 9: 100.00% uptime, 32 checks
Sep 10: 100.00% uptime, 32 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 32 checks
Sep 13: 100.00% uptime, 32 checks
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 32 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 16 checks
Aug 22 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
144ms
DNS 41ms TCP 2ms TLS 4ms TTFB 144ms
arn
509ms
DNS 177ms TCP 104ms TLS 107ms TTFB 508ms
bom
838ms
DNS 260ms TCP 1ms TLS 9ms TTFB 838ms
ord
180ms
DNS 147ms TCP 1ms TLS 3ms TTFB 179ms
sin
362ms
DNS 135ms TCP 2ms TLS 4ms TTFB 362ms
sjc
164ms
DNS 88ms TCP 1ms TLS 3ms TTFB 164ms
syd
523ms
DNS 300ms TCP 0ms TLS 3ms TTFB 522ms
yyz
159ms
DNS 61ms TCP 8ms TLS 12ms TTFB 158ms

What Buildkite does

Buildkite runs CI/CD pipelines in which the build agents run on infrastructure you control. Buildkite hosts the pipeline definitions, scheduling and the web dashboard, while the machines that compile and test code stay inside your own network. Engineering teams pick it to keep source and build secrets off a vendor's servers while still getting hosted orchestration.

What an outage looks like

Builds sit queued and never start, because agents poll the Agent API for work and receive nothing. Jobs already running usually finish, since that work happens on your machines, but results fail to upload and the pipeline never advances. The dashboard may be slow or error, and REST API calls from deploy scripts start failing.

What to do about it

Read the component list on Buildkite's status page rather than the headline: Web, Agent API, REST API, Remote MCP Server and Job Queue each fail on their own, and Job Queue is the one that stalls builds. Agents reconnect by themselves once the API returns, so restarting them rarely helps. Avoid re-triggering builds, which deepens the backlog.

Is it down for everyone, or just you?

If this page says Buildkite is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

Buildkite outage FAQ

Do my builds keep running during a Buildkite outage?
Partly. Buildkite agents run on your own infrastructure, so a job already executing keeps compiling and testing. What breaks is coordination: the agent cannot report results back, and no new jobs are dispatched. The build looks stuck in the dashboard even though the machine is working. Agents reconnect and report once the Agent API recovers.
Why are my builds queued but not starting?
That is the usual shape of a Buildkite incident. Agents ask the Agent API for work on a poll, so when that component is degraded they sit idle while the queue grows. Check the Job Queue and Agent API components specifically, since the web dashboard can be fully operational while dispatch is broken.
Should I restart my build agents?
Usually not. Agents retry their connection automatically and rejoin when the API returns, so a restart adds churn without speeding recovery, and it loses any job currently executing on that machine. Restarting is worth it only if an agent stays disconnected after Buildkite reports the incident resolved.
Is my code at risk during an outage?
No. Buildkite stores pipeline configuration and build metadata, while source lives in your Git host and the build work happens on your agents. An outage delays feedback rather than losing code. Artifacts uploaded during the incident may need re-uploading once the REST API is available again.

How we measure this

  • We request Buildkite's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Buildkite publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Buildkite goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required