Summary

The framework's dev error page (rendered for `Wheels.DataSourceNotFound`, `Wheels.RouteNotFound`, generic exceptions, etc.) is served with HTTP 200. Anything monitoring, caching, retrying, or alerting on status codes is misled into thinking the request succeeded.

Repro

```
$ wheels new blog && cd blog && wheels start

(Trigger any error condition, e.g. visit a route that 404s or fails on a missing datasource)

$ curl -o /dev/null -w "%{http_code}\n" http://localhost:8080/posts
200
```

…with `Wheels.DataSourceNotFound` rendered in the body.

Same for `Wheels.RouteNotFound`, `Wheels.RecordNotFound`, and uncaught Lucee exceptions.

Expected

• 5xx for framework errors (DataSourceNotFound, uncaught exceptions, internal errors).
• 404 for RouteNotFound and RecordNotFound.

The framework's own code path even calls `$header(statusCode = 404)` in `vendor/wheels/Global.cfc:2137` (visible in the stack trace of a triggered `RouteNotFound`), so the intent is there. Something downstream is overriding it back to 200.

Likely cause

The dev error page handler probably writes the response body before calling `$header(statusCode = ...)`, and Lucee has already flushed/committed at 200. Or the error page is rendered through a path that doesn't propagate the status code.

Worth checking:

• `vendor/wheels/Global.cfc` around line 2137 — confirm the `$header` call lands before any output
• `vendor/wheels/dispatch/Errors.cfc` (or equivalent) — error rendering path
• Any `$cleanContent()` / `$flush()` calls that might happen before the status header is set

Severity

Major. Users running `curl` in CI, scripts, or monitoring tooling against a running dev server can't distinguish error responses from successful ones.

Source

Fresh-VM onboarding journal, 2026-04-25, finding #8.