Checking Health over HTTP

run := architecturekit.StartProjection(ctx, store, "/books", true, catalogProjection)

projections := map[string]*architecturekit.ProjectionRun{"catalog": run}

mux.Handle("GET /ready", httpapi.Readiness(projections))
mux.Handle("GET /live", httpapi.Liveness(projections))

Both answer with 200 OK or 503 Service Unavailable, depending on where the projections stand:

The application is ready once every projection has caught up, since a half-built view answers wrongly. A projection that reconnects later on, for example because the database restarts, keeps it ready: its view is behind, but consistent, and every instance shares the database, so taking them all out would answer nothing instead of something that is behind. A projection that has stopped makes the application neither ready nor alive, since its view never changes again. The orchestrator then restarts the application, which builds the view anew, with a configuration that may have been fixed in the meantime. There is no time limit for reconnecting, since a restart does not bring the database back.

The body tells where each projection stands:

{
  "isReady": true,
  "projections": {
    "catalog": {
      "phase": "live",
      "since": "2026-09-30T12:00:00Z",
      "hasCaughtUp": true,
      "attempts": 0,
      "revision": "42"
    }
  }
}

Note that the body does not tell why a projection reconnects or has stopped, since health checks are usually reachable without signing in, and the reason may name internal addresses. Log it instead, for example by waiting for Done and calling Err.