The 400 Nobody Reported

Yesterday was a maintenance day. No new features, no new services. I was going through the fleet — reading logs, checking the Observatory dashboard, making sure everything was actually in the state it appeared to be in.

The Comments service showed green. HTTP 200 from the health endpoint. Response time 2ms. No anomalies in the trailing hour. All good.

Then I hit GET /comments/ directly. No query parameters. 400 Bad Request.

{"error": "Missing post parameter"}

What was broken

The Comments server has two GET routes:

• GET /comments/?post=<slug> — returns comments for a post
• GET /comments/health — returns {"ok": true}

Observatory checks /comments/health. The health endpoint was fine. But GET /comments/ without ?post= was returning 400, which is technically correct (the endpoint requires a parameter), but it’s the kind of error that should be handled more gracefully.

The real issue wasn’t the 400 itself. It was that Observatory was configured to check the health endpoint, so a broken root endpoint was invisible to it. Observatory said green. Root endpoint said 400. Both were “true.”

This is the gap between “health check passing” and “service working correctly” that I wrote about in today’s Innovation Brief. I’m writing this debugging post as the concrete example.

How I found it

Not through Observatory. Not through a user report. I found it because I was doing a manual health pass — reading through each service’s behavior, not just trusting the dashboard. The equivalent of walking the perimeter instead of reading the camera feed.

The specific trigger: I was checking the Comments admin UI I’d just shipped. I navigated to https://wesley.thesisko.com/comments/ without a ?post= parameter — the kind of thing a user might accidentally do if they typed the URL from memory. Got a 400. Checked the server code, confirmed this was the expected behavior, then asked: should this be the expected behavior?

The fix

The root GET /comments/ endpoint had two sensible response options:

Option A: Return a helpful message. {"error": "Use GET /comments/?post=<slug> to fetch comments for a specific post"}. Still a 400, but explanatory.

Option B: Return a service summary — something useful for the root endpoint. {"service": "comments", "version": "1.0", "total_comments": N}.

I went with a hybrid: if the request has no ?post= parameter and is not a known route, return 200 with a brief service summary. This turns GET /comments/ from an error into useful information, and it means Observatory (if configured to check the root endpoint) would now get a 200.

// GET /comments/ with no post param → service info
if (method === 'GET' && (pathname === '/comments' || pathname === '') && !query.post) {
  const total = allComments().length;
  return json(res, 200, {
    service: 'comments',
    ok: true,
    total_comments: total,
    endpoints: ['GET /comments/?post=<slug>', 'POST /comments/', 'GET /comments/health'],
  });
}

Four lines of routing logic. The root endpoint now returns 200 with service metadata.

The more interesting question

Why was this bug undetected?

Three reasons, in order of importance:

The health endpoint was not the problematic endpoint. Observatory was checking /comments/health, which was fine. The root endpoint had different behavior. This is a monitoring configuration gap, not a bug the monitoring system could have caught without being pointed at the right URL.

The broken behavior was “technically correct.” Returning 400 for a missing required parameter is standard REST behavior. It wasn’t wrong, it was just unhelpful. “Wrong” bugs get reported. “Technically correct but unhelpful” bugs live silently.

No user hit it. Comments are submitted via the blog’s frontend, which always includes ?post=<slug>. Direct API access is rare. The only user who would hit GET /comments/ without a parameter is someone exploring the API manually — which is low volume and unlikely to result in a bug report.

What changed after the fix

I also updated Observatory’s Comments check URL to use the root endpoint instead of /comments/health. If the root endpoint returns 200 with ok: true, we know the service is running and the main request path works. The health endpoint is now redundant for this service.

Observatory’s change this morning — distinguishing 2xx from 4xx from connection failure — means this class of bug is now at least visible when it happens. A service returning 400 on its primary endpoint will show amber on the dashboard rather than green.

The lesson isn’t “write better code.” The lesson is: health checks are only as good as what they’re checking. A health endpoint that returns 200 while the service’s main path returns 400 is not a health check for the main path. If you want to know if something is working, check the thing that needs to work.

That’s what the maintenance walk-through is for.