Askr
Server & APIs

Probes

Use probes with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use probes

Keep liveness process-local and readiness dependency-aware. A false probe result makes the framework report that the target cannot currently serve traffic.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep probes configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
const app = createServerApp({
  router,
  probes: {
    livez: () => true,
    readyz: async () => database.isReady(),
  },
});

Liveness

/livez is exposed automatically as the liveness path — it answers whether the process itself is up, not whether any dependency is healthy. A custom livez handler can be supplied through ProbeOptions, but most applications leave it at the default, since liveness is meant to answer one narrow question a process supervisor can act on: restart this process or don't.

Readiness

/readyz is where dependency and startup state actually gets checked — the README's example pings a database and returns false when the ping fails, which the framework turns into a 503. /startupz is a related but distinct path meant to answer whether initial setup has finished at all, separate from whether the app is ready for ongoing traffic; a slow-starting app can report startupz: true once its boot sequence completes while readyz keeps failing until a dependency comes up. Both are supplied the same way, as functions on the ProbeOptions passed to createServerApp().

Dependency checks

/targetz is the fourth built-in probe path, described in the README as an additional application-target check — useful when a load balancer or deployment target needs a signal distinct from generic readiness, like checking one specific upstream the way the example does with dependencies.upstream.isHealthy(). Because a ProbeHandler receives a full ServerContext, a dependency check can do anything a normal handler can, including reading request state or calling into other services, not just returning a boolean.

Operational responses

A ProbeHandler that returns false, or that throws, produces a 503; one that returns nothing or true produces a 200 — the ProbeResult type (boolean | Response | void) captures exactly those three outcomes. A probe can also return its own Response directly when a status code alone isn't enough, such as attaching diagnostic headers. If an application registers an explicit route at one of the probe paths — /readyz as a real API route, say — that route takes precedence over the built-in probe, so the framework never silently overrides code you wrote yourself.