Liveness by default. Dependencies only when asked for.

THIS PATH IS THE ONE THE LOAD BALANCER AND ECS BOTH PROBE. <<< The target group em-production-mcp-tg health-checks /health with a 10 s timeout, and the task definition health-checks the SAME path from inside the container with curl -f http://localhost:8000/health and a 5 s one. So whatever this endpoint waits on becomes a reason to kill the task — and, because payshell starts only once mcp-server reports HEALTHY, a reason the REPLACEMENT task can never come up either.

On 2026-09-08 that is exactly what happened. Supabase started answering 57014 canceling statement due to statement timeout at 23:05:06Z; this handler queried it; /health went from 50 ms to 24.8 s; both watchdogs fired; every replacement task sat PENDING with payshell waiting on a container that would never be healthy; the target group held ZERO targets for twenty-nine minutes. A degraded database became no service at all, which is strictly worse than serving degraded.

So the default answer is about THIS PROCESS and nothing else: no database, no RPC, no S3, no facilitator, no thread hand-off. It cannot be slower than building a dict, so it cannot be the reason a task dies.

The dependency picture did not go away — ask for it with ?deps=true (?force=true implies it, which is what the admin dashboard already sends). That path answers 503 when a critical component is down, and it is bounded so that a hung dependency cannot hang the caller either.

Response Codes:

• 200: process is alive (liveness), or system healthy/degraded (deps)
• 503: deps only — a critical component is unhealthy

Args: force: Run the dependency checks fresh, bypassing the 30 s cache deps: Include the dependency checks

Returns: JSON object; probe names which of the two answers this is