Why a 200 status code is not a passing test
A short post about why DevFlow runs response-shape assertions by default — and why we think most monitoring tools are running blind.
the bug
A regression at a previous job: a feature flag was supposed to gate a new field in the response. The flag flipped one minute ahead of the API change, and the response went from:
{ "ok": true, "data": { "id": 1, "amount": 100 } }to:
{ "ok": true, "data": { "id": 1 } }For 14 minutes. amount was missing on every successful response. Every single check returned 200. Our monitoring told us we were fine.
The customer found it. They emailed us at 11pm.
the fix
Three lines of YAML:
assertions:
- body_jsonpath:
path: $.data.amount
type: numberNow the monitor knows what "ok" actually means.
why everyone doesn't do this
Because it's a fight, internally. Adding the assertion is easy; knowing what the contract is is the hard part. It requires the team that owns the API to write down what their API actually returns and what's stable and what isn't.
That conversation is the one DevFlow tries to make easier — not by automating it, but by giving it a place to live (the monitor file, in your repo, reviewed in PR).
The shortest path to assertion happiness is taking the Quickstart and adding three JSONPath checks the first time you ship a monitor. After that, every regression you catch becomes the case for the fourth.
— Rohan