Platform status

Checking Cobre's status…

Asking the platform now.

• API Checking
• Database Checking
• Workers Checking
• Model providers Checking

What these four mean

API answered, because you are reading this — the page could not have been filled in otherwise. It says nothing about whether a run would succeed, which is what the other three are for.

Database is reachable and its schema is the one this build expects. A schema behind the code is reported as degraded rather than down: it is what a deploy in flight looks like from the outside, and requests are still being served while it lands.

Workers is the one a failing run usually points at. Cobre’s API accepts a run and a worker executes it, so an API answering perfectly in front of a fleet that has stopped beating will take your run and never start it. That state is down, not degraded — nothing can execute.

Model providers is whether each configured provider answered its last check. One family failing is degraded, because runs naming a different one still work; all of them failing is down. Before the first check has run there is nothing to report, and the page says not measured rather than guessing.

What this page does not show

No numbers. Not the queue depth, not how many workers are up, and not what is left on any provider account. This page is public — anyone with the address can read it — so it answers whether the platform works, not how it is doing.

Those readings exist and they are the operator’s: GET /system/queue and GET /system/workers answer them at the admin floor, GET /system/metrics exposes the whole declared catalogue for a scraper, and the credit balance drives an alert rule that pages the people who can top it up.

Reading it from your own code

The endpoint behind this page takes no credential and returns the same document:

curl https://your-deployment.example.com/system/status

{
  "status": "degraded",
  "components": [
    { "name": "api", "status": "operational", "detail": null },
    { "name": "database", "status": "operational", "detail": null },
    { "name": "workers", "status": "operational", "detail": null },
    { "name": "providers", "status": "degraded", "detail": "not responding: gateway" }
  ],
  "checked_at": "2026-08-17T20:14:32Z"
}

status is the worst of the components that could be read, and unknown never becomes it: a component nobody has measured is not an outage. The four states are operational, degraded, down and unknown, and the set will not grow without a note here.

If you are polling this to decide whether to submit work, poll it no faster than this page does — every thirty seconds is plenty for a reading the platform itself refreshes on a timer. And if you are checking whether your own runs are healthy rather than the platform’s, alert rules are the instrument: they watch your workspace’s error rate, latency and spend, and they can call a webhook instead of waiting for somebody to open a page.