Skip to content

Interface: EnrichedHealthResponse

@kortexya/reasoninglayer


@kortexya/reasoninglayer / EnrichedHealthResponse

Defined in: src/types/health.ts:34

Enriched health response with component statuses, build info and the identity of the engine process that answered.

The engine always sends bootId, startedAt, uptimeSeconds and buildInfo. They are optional here only because a gateway-fronted deployment can answer the health route with an empty or partial body; the SDK then leaves them absent and never invents a value.

optional bootId?: string

Defined in: src/types/health.ts:41

Identity of the engine process that answered (a UUID). It is stable for the life of the process and different after every restart (a rebuild, a crash, a redeploy). Derived conclusions are process-scoped, so a client that sees bootId change must treat its derived view as reset.


optional buildInfo?: BuildInfoDto

Defined in: src/types/health.ts:48

Build information for the running server.

Optional: some deployments (typically the gateway-fronted production health endpoint) omit build info and return null here.


components: ComponentHealthDto[]

Defined in: src/types/health.ts:50

Health status of individual components.


optional sovereign?: boolean

Defined in: src/types/health.ts:62

Whether sovereign mode (OSFKB_SOVEREIGN_MODE) is on: every configured endpoint is inside the customer network. The detail is at GET /api/v1/sovereignty. Absent when the answering deployment omits it.


optional startedAt?: string

Defined in: src/types/health.ts:52

Wall-clock instant this process started (RFC 3339, UTC).


status: string

Defined in: src/types/health.ts:54

Overall health status.


optional uptimeSeconds?: number

Defined in: src/types/health.ts:56

Whole seconds since this process started; monotonic within one bootId.