`/health` reports "ok" when only one dependency is actually up

Nobody has started this yet — be first.

Business impact

GET /health exists for exactly one reason: to let a Docker healthcheck, a Kubernetes readiness probe, or a load balancer decide whether to keep sending this instance traffic. Right now, if Postgres goes down but Redis is still reachable (or vice versa), /health reports 200 { status: "ok" } anyway. The orchestrator sees a healthy instance and keeps routing real user traffic to it -- every POST /shorten and every cache-miss GET /:code behind that "healthy" instance then fails with a 500. On-call ends up chasing a spike in 500s against a fleet that every dashboard says is green, because the one signal that's supposed to catch this is lying. It also directly contradicts this project's own README, which explicitly promises "Returns 200 only if both checks pass, 503 otherwise."

Problem

GET /health returns 200 { status: "ok" } as long as either Postgres or Redis is reachable -- not both.

Current behavior

With Postgres down and Redis up (or vice versa), GET /health still returns HTTP 200 { status: "ok" } instead of 503 { status: "degraded" }.

Expected behavior

GET /health must return 200 { status: "ok" } only when both Postgres and Redis checks succeed. If either one fails, it must return 503 { status: "degraded", checks: {...} }, with the failing dependency marked "error" in the checks object.

Steps to reproduce

with the app running and Postgres reachable but Redis stopped, e.g.:

docker compose stop redis curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3003/health

Expected: 503

Actual: 200

Or, without touching real infra, run this ticket's test (see verification below) -- it forces one dependency to fail via a mock and asserts on the status code.

Why this matters

Both dependency checks (SELECT 1 against Postgres, PING against Redis) are already run correctly via Promise.allSettled -- the bug isn't in how the checks happen, it's in how their two boolean results get combined into one overall verdict. "Healthy" should mean every check passed, not some check passed. The boolean expression combining checks.postgres === 'ok' and checks.redis === 'ok' is using the wrong operator for that.

Suggested approach

Find the line in src/routes/health.js that assigns const healthy = .... Think about what "the service is healthy" should mean when there are two independent checks, then look at which boolean operator is actually being used to combine them.

Acceptance criteria

GET /health returns 503 when Postgres is unreachable and Redis is fine.
GET /health returns 503 when Redis is unreachable and Postgres is fine.
GET /health still returns 200 when both are reachable (don't break the happy path).
The checks object in the response body still correctly reports "error" for whichever dependency actually failed (this part already works and must keep working).

Verification

npx jest --config practice-tickets/jest.config.js practice-tickets/tests/01-health-check-false-positive.test.js

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/health-check-false-positive

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/health-check-false-positive

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

URL Shortener — Redirect Latency vs. Click-Count Correctness

A production-quality Express/Prisma/Redis URL shortener whose central engineering problem is keeping the redirect path fast while still counting every click correctly -- async, fire-and-forget click logging that never adds latency, backed by a single atomic SQL increment instead of a read-then-write.

Fork on GitHub

Download

Setup

URL Shortener — Redirect Latency vs. Click-Count Correctness

git clone <your-fork>
cd url_shortener
cp .env.example .env
npm install                       # also runs `prisma generate` via postinstall
docker compose up -d postgres redis   # or point .env at Postgres/Redis you already run
npm run prisma:migrate:dev        # applies prisma/migrations, creates the db schema
npm run dev                       # nodemon, http://localhost:3003