# Probes

> Probes at the Askr server boundary, with validated input and explicit failure states.

Source: [https://askrjs.com/docs/server/probes](https://askrjs.com/docs/server/probes)

Status: stable. Packages: @askrjs/askr.

**Published packages are authoritative.** Examples may lag behind a published contract. When guidance differs, verify the exports and TypeScript declarations in your installed package, then file an issue.

## Example

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

```tsx
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.

## Documentation navigation

[Previous](https://askrjs.com/docs/server/realtime/index.md) | [Next](https://askrjs.com/docs/authentication/index.md)