Status & health
Every service 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 services 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 running while a newer change is still building.
Health by service shape
What "healthy" means depends on the mode the service runs in:
| Shape | Health values |
|---|---|
| Standard web services and databases | starting, online, degraded, offline |
| Serverless | the standard values plus sleeping — idle by design, waiting for the next request. Sleeping is not an error. |
| Cron | starting, then online once the job is deployed and its schedule is registered — it does not need to be mid-run. The console labels a cron's online as Scheduled. |
| Volume | the standard values — a volume service is an always-on web service with a persistent disk attached. |
What the status badge means
The single badge on a service derives from the three axes:
- Online (green) — the service is up and running.
- 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, and no rollout is in flight to explain it.
- 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 when it started failing and the failure's message, recorded verbatim, never paraphrased. Fix the cause and redeploy, or roll back.
Warnings are non-fatal notes that never turn the badge red — for example "2 of 3 replicas ready", or "running previous version" while a rollout is in flight. They usually explain a Degraded badge or an in-progress change.
One warning worth knowing about: on a brand-new service, the platform-assigned URL can lag DNS. The service is genuinely up — health reads Online — but the address hasn't propagated yet, so the URL may not answer for a few minutes. The status carries a warning coded dns_propagating while this lasts, and it clears itself. This is about the platform-assigned URL only — custom domains track their own verification status and are never folded into it.
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.
- Read the error on the service. The message is the real failure detail, verbatim — it usually names the fix, whether that's a bad image reference, a failed apply, or a crash on boot.
- Check the service's logs — a crash-looping process keeps health at Offline no matter how long you wait.
- Redeploy the service. A fresh deploy re-runs the whole pipeline and replaces a stuck rollout.
- 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: status.koo.io 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.