# 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](/api/services) returns all three inline (see the [service object](/api/objects/service) for the exact fields).

## The three axes

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](/docs/services/service-modes) the service runs in:

## What the status badge means

The single badge on a service derives from the three axes:

- 
- 
- 
- 
- 
- 
- 
- 
-

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](/docs/deploy/deployments-and-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](/docs/networking/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.

> **Note:**
>
> 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:

1. 
2. 
3. 
4. 
5.

## Koo platform status

Service status describes _your_ services. Platform-wide health is a different surface with its own vocabulary: [status.koo.io](https://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.