# Status & health

Every [service](/docs/apps/apps-and-services) 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](/api/apps) 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 ready while a newer change is still building.

## Health by service shape

What "healthy" means depends on the shape of the service:

## 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/apps/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 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.

> **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.

## Koo platform status

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