heyrian.dev
← Lesson
Lab

Probe decisions

Evidence desk

  • Endpoint contract: /startupz reports local initialization only; /readyz also requires database access and local progress; /livez checks local progress.
  • Initialization finishes in 12 seconds. The database then fails for 40 seconds. The process reconnects without a restart.

Repair the probe configuration

Change the HTTP paths and startup allowance for this fixture. The HTTP port is fixed at 8080; every period is five seconds and timeout one second. Readiness uses failureThreshold 2 and successThreshold 1; liveness uses failureThreshold 3. This checks endpoint behavior and the stated allowance, without running Kubernetes.

For this first catalogue, initialization takes 12 seconds; its nominal startup requirement is 25–60 seconds. The larger index level replaces that requirement with 100–150 seconds.

Sign in with a free account to check the easy configuration.

Inspect code and system behaviorReplay the starting or last checked configuration

This replay uses this level’s starting configuration. Check a change to update it. Code is replayed from saved executions; lifecycle behavior and the terminal are modeled. The hard investigation uses its authored evidence above for the OOM diagnosis.

Speed
Model 0sLocal process can make progress.

Waiting for the matching handler recording…

Recorded TypeScript execution
Speed
health.ts + recorded callLoading saved call
export type HealthState = { initialized: boolean; stuck: boolean; databaseDown: boolean };

/** The HTTP server and recorded calls use this same handler. */
export function statusFor(path: string | undefined, state: HealthState) {
	if (path === '/startupz') {
		return state.initialized ? 200 : 503;
	}
	if (path === '/livez') {
		return state.stuck ? 503 : 200;
	}
	if (path === '/readyz' || path === '/tickets') {
		const canServe = state.initialized && !state.stuck && !state.databaseDown;
		return canServe ? 200 : 503;
	}
	return 404;
}

const path = "/startupz";
const state = {"initialized":true,"stuck":false,"databaseDown":false};
const status = statusFor(path, state);
console.log(status);
Recorded output 
Loading…
Call stack and observed values

Inspecting the handler behind this observation. Code steps do not advance model time. With Follow code enabled, the system player steps through this call before advancing.

ClientGET /tickets
Service
Endpoint eligible
New requests reach this Pod GET /tickets → 200
Worker node · logical view
KubeletDirect Pod checks
PodReady true
Audio-guide catalogueContainer · start #1
startup0 / 6
readiness0 / 2
liveness0 / 3
Local process responding
Container restarts 0Pod identity stays the same
Required dependency
DatabaseAvailable
Outside the application container

Solid path: eligible traffic. Dashed path: withdrawn or unsampled. Counts: consecutive failures / limit. Select a handler to inspect its code. Probe responses precede any restart; the container below them shows the resulting state.

Evidence terminalModel 0s · modeled output

sim> kubectl get pods

NAME          READY  STATUS   RESTARTS
catalogue-7   1/1    Running  0

Supported inspection commands only. No shell or cluster connection.

Replay detailsObservations, provenance and model assumptions
What is recorded, and what is modeled?Provenance and assumptions

The health handler runs in the real HTTP fixture. Its code, stack, values and output here come from saved Lovelace executions of the shown call. No reader code runs live.

The lifecycle and terminal are a deterministic teaching model: five-second samples, two readiness failures, three liveness failures, one sample of routing delay, immediate restart, 20-second restart initialization (or 50 seconds in the startup case). Startup gates regular probes. This is one replica, without restart backoff, termination grace, connection draining or resource contention. These are not captured cluster events.

Progressive hintsOpen only when you need a next step
Hint 1

Which endpoint can still return 200 while catalogue requests fail?

Hint 2

Keep initialization, serving ability and recoverable local progress as separate questions.

Compare a worked responseOne defensible answer, with verification

Use /readyz for readiness. The starter uses initialization as permission to serve forever. /livez should stay local, and /startupz should bound initialization. With the database unavailable, the endpoint contract gives readiness 503 and liveness 200; dependency recovery restores readiness. A local stall still fails liveness.

Reference configuration: startup /startupz, readiness /readyz, liveness /livez, startup failures 6, period five seconds. In a disposable cluster, confirm startup, dependency failure without restart, dependency recovery, then one local-failure restart and restored Service requests.