A 200 status code is not a passing test.

DevFlow assertions check what your customers’ code checks: a request, a response, the shape of the data, the latency, the headers. Status codes alone miss the most common contract regressions — a missing field in an otherwise-200 response.

The vocabulary

assertions:
  - status_eq: 200
  - latency_lt_ms: 800
  - header_eq: { name: Content-Type, eq: application/json }
  - header_present: X-Request-Id
  - body_jsonpath: { path: $.status, eq: ok }
  - body_jsonpath: { path: $.data.user.id, type: string }
  - body_json_schema: { schema_ref: workspace://schemas/charge-v3.json }
  - body_regex_matches: "^OK \\d{4}$"
  - body_jsonpath: { path: $.errors, type: array, length_eq: 0 }
  - negate: true
    body_jsonpath: { path: $.deprecated_field, type: string }

Strictness vs flapping

Assertions over-tightened are the biggest cause of monitor flapping. Be honest about what fields are stable. If a payload includes a generated request_id, assert presence, not value. Rohan covered this in “Why a 200 status code is not a passing test” — worth a read.

See the docs on response-assertions and troubleshooting-flapping-monitors for the full reference.