Where does this status come from?

From CircleCI's own status page API at https://status.circleci.com. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are CircleCI's words.

How can my agent or app check CircleCI status?

Fetch https://upbutler.com/status/circleci/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"circleci"}, on https://upbutler.com/mcp/public.

How do I know whether an outage is mine or CircleCI's?

Add "circleci" to the dependencies of your UpButler workspace. When one of your monitors fails while CircleCI has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

Is CircleCI down?

Right now

No. CircleCI is operational.

No incidents reported.

Read from status.circleci.com 2 min ago · every 120s

For agents

proceed

Proceed.

GET upbutler.com/status/circleci/status.agent.json

MCP: upstream_status {"service":"circleci"}

Hosted CI pipelines and runners.

What CircleCI reports

Operational

Taken as is from CircleCI's own status page API. Incident titles and component names below are theirs.

Open status.circleci.com

UpButler's independent probe

There is no keyless endpoint of CircleCI that says anything useful, so UpButler does not probe it. To check your own CircleCI account, add a monitor with your key: it is yours alone and catches what a shared probe cannot.

CircleCI components

39 operational

CircleCI Dependencies

AWSOperational
Google Cloud Platform Google Cloud DNSOperational
Google Cloud Platform Google Cloud NetworkingOperational
Google Cloud Platform Google Cloud StorageOperational
Google Cloud Platform Google Compute EngineOperational
mailgun APIOperational
mailgun Outbound DeliveryOperational
mailgun SMTPOperational
OpenAIOperational
Auth0 User AuthenticationOperational

Upstream Services

Atlassian Bitbucket APIOperational
Atlassian Bitbucket Source downloadsOperational
Atlassian Bitbucket SSHOperational
Atlassian Bitbucket WebhooksOperational
Docker HubOperational
GitHub Git OperationsOperational
GitHub Pull RequestsOperational
GitHub API RequestsOperational
GitHub PackagesOperational
GitHub WebhooksOperational
GitLabOperational
Docker RegistryOperational
Docker AuthenticationOperational
Anthropic api.anthropic.comOperational
packagecloud.ioOperational

Docker JobsOperational
Machine JobsOperational
macOS JobsOperational
Windows JobsOperational
Pipelines & WorkflowsOperational
CircleCI APIOperational
CircleCI UIOperational
ArtifactsOperational
RunnerOperational
CircleCI WebhooksOperational
CircleCI InsightsOperational
CircleCI ReleasesOperational
Notifications & Status UpdatesOperational
Billing & AccountOperational

CircleCI incidents, last 90 days

7 finished incidents seen since UpButler started tracking on 2026-10-10, 2 of them rated major or critical by CircleCI. A typical one lasted 1 h 39 min; the longest 14 h 36 min.

Started (UTC)	Incident	Impact	Lasted
2026-10-09 11:33	Delay in data appearing in UI and API	major	14 h 36 min
2026-10-08 13:00	Elevated wait times for machine jobs	minor	3 h 35 min
2026-10-07 18:54	Increased task wait times for Docker Gen2	minor	1 h 11 min
2026-10-07 14:27	Elevated level of infra fails on customer jobs	minor	54 min
2026-10-07 13:40	Delay on starting Machine Job Tasks	minor	26 min
2026-10-06 16:00	Delays in pipelines, workflows, UI data, and notifications	major	5 h 18 min
2026-10-01 09:06	Delays starting Gen 2 Docker Jobs	minor	1 h 39 min

Tell your outage from CircleCI's

Declare that your project depends on CircleCI. When one of your monitors fails while CircleCI has an incident that began around the same time, UpButler tags your incident "likely upstream" with their incident linked, says so in the alert and the AI report, and tells your on-call agent not to change code.

npx upbutler init finds the dependency from your env var names and packages. The catalog, dependencies and upstream-aware incidents are on every plan, including Free.

Start free How it works

upbutler.yaml

# upbutler.yaml
dependencies:
  - circleci

Ask before you retry

curl -s https://upbutler.com/status/circleci/status.agent.json

status.agent.json (live)

{
  "schema": "upbutler.upstream-status/v1",
  "service": "circleci",
  "verdict": "proceed",
  "status": "operational",
  "reason": "No incidents reported",
  "retryAfterSec": null,
  "incident": null,
  "probe": null
}

Questions

Is CircleCI down right now?: No. As of 2026-10-10 05:11 UTC, CircleCI is operational. This page reads the status again every 2 minutes.
Where does this status come from?: From CircleCI's own status page API at https://status.circleci.com. UpButler reads it once for everyone (not once per visitor) every 120 seconds with conditional requests, and shows it unchanged: incident titles and component names are CircleCI's words.
How can my agent or app check CircleCI status?: Fetch https://upbutler.com/status/circleci/status.agent.json: a small JSON document with a verdict (proceed, retry, fallback or pause) and retryAfterSec. No key is needed. The same answer is an MCP tool, upstream_status {"service":"circleci"}, on https://upbutler.com/mcp/public.
How do I know whether an outage is mine or CircleCI's?: Add "circleci" to the dependencies of your UpButler workspace. When one of your monitors fails while CircleCI has an incident that began around the same time, your incident is tagged "likely upstream" with their incident linked, and your on-call agent is told not to change code.

More in code, packages and workflows

UpButler is not affiliated with CircleCI. Status and incident text belong to CircleCI and are read from their public status source; the probe result is UpButler's own measurement.