Status & health
Every service in an app reports status on three independent axes: applied — did Koo accept and apply your configuration; build — for services built from source, how the build is going; and health — what the running service is observably doing right now. The console folds them into a single badge; the apps API returns all three inline (see the service object for the exact fields).
The three axes
| Axis | Values | What it tracks |
|---|---|---|
| Applied | pending, applied, error | The pipeline: has Koo's hosting layer accepted and applied your latest change? |
| Build | pending, building, built, failed | The build, for services that build from source. Container-image deploys have no build axis. |
| Health | by service shape — see below | Runtime truth, observed from the running service. Always present; a service Koo hasn't observed yet reports starting. |
The axes move independently. A service can be fully applied and still down — the new code crashes on boot — or up and ready while a newer change is still building.
Health by service shape
What "healthy" means depends on the shape of the service:
| Shape | Health values |
|---|---|
| Always-on services | starting, online, degraded, offline |
| Serverless (scale-to-zero) | the always-on values plus sleeping — idle by design, waiting for the next request. Sleeping is not an error. |
| Cron | the same always-on values. A cron service is online whenever its schedule is registered — it does not need to be mid-run — so the console labels that state Scheduled. |
What the status badge means
The single badge on a service derives from the three axes:
- Online (green) — the service is up and ready.
- Scheduled (green) — a cron service is deployed and will run on its schedule. (It is
onlineunderneath; the label just reads better for a job.) - In progress (blue) — the service is starting, or a new version is rolling out.
- Queued… / Building image… (blue) — the latest deploy's build is running.
- Sleeping (neutral) — a serverless service is idle; the next request wakes it.
- Not deployed (neutral) — the service exists but has never been deployed.
- Degraded (orange) — partially ready; a warning next to the badge says what's off.
- Offline (orange) — applied, but not ready.
- Build failed / Deploy failed / Apply failed (red) — the pipeline could not ship your change.
Red always means the pipeline failed. A runtime dip is never red: an applied-but-down service shows orange Offline, because your deploy went through — it's the running process that needs attention. The pipeline side is covered in deployments & rollback.
Errors and warnings
When something fails, the service carries a list of errors, each tagged with the axis that produced it — applied, build, deploy, or health — along with the message and when it started failing. Fix the cause and redeploy, or roll back.
Warnings are non-fatal notes that never turn the badge red — for example "1 of 3 locations unhealthy", or "running previous version" while a rollout is in flight. They usually explain a Degraded badge or an in-progress change.
A service also keeps a single, stable URL: the address stays put through redeploys, sleeps, and dips rather than flickering with the status.
Status freshness
Health is observed, not declared: Koo watches the running service and stamps each status with when it last looked (statusObservedAt in the API). If observation stops for more than 5 minutes, the console adds an "as of …" hint next to the status so you know the read is stale.
Observation runs on a short cadence, so the badge can lag reality by a brief interval — typically seconds while you're watching. A crash can flip a service to Offline before the view catches up.
When status looks stuck
If a service sits in In progress, or shows an "as of …" hint long after a change:
- Open the service's Deployments tab and check the latest deployment's timeline — a deploy stuck in a build or apply phase names the step that hasn't finished, and its build logs show why.
- Run Re-sync from the app page. This re-applies the app's desired state to Koo's hosting layer and is safe to run at any time — if nothing drifted, it's a no-op.
- Check the service's logs — a crash-looping process keeps health at Offline no matter how many times you re-sync.
- Still stuck? Contact support. If an API call failed along the way, include the
requestIdfrom its error response — it lets support trace exactly what happened.
Koo platform status
Service status describes your services. Platform-wide health is a different surface with its own vocabulary: koo.io/status lists Koo's components and any active or recent incidents — updates written and published by the Koo team, not per-service axes.
If the status page reports an incident, your status reads may be stale or your deploys delayed until it resolves. Your running services keep running on Koo's hosting layer independently of the incident.