Error tracking vs. contract monitoring: what each one structurally can't see

The fair question every engineer asks: wouldn't this just show up as an error my tracker already catches? Half the time, yes. Knowing which half is the whole decision.

Where your error tracker genuinely covers it

Strict servers reject bad requests; your client throws; the tracker catches it. If your team triages agent errors with discipline, you'll eventually trace it to the schema. If every server you depend on validates strictly and your failures all throw loudly, contract monitoring is a nicer root-cause label on something you'd have found, and 'nicer' is not a budget line. Be honest about this case: some teams don't need it.

The four gaps that remain

One: lenient servers return 200 for outdated shapes and misroute silently, no exception exists to catch. Two: even caught errors arrive as stack traces, not causes; the schema diff, the affected fields, and the blast radius still require archaeology. Three: error tracking is after-the-fact; a CI contract gate fails the build before deploy, including when the server drifted under an open PR. Four: detection needs traffic, low-usage tools break Friday and surface Monday, while a poller catches drift whether anyone called the tool or not.

Use both

This isn't a replacement pitch. Keep the error tracker for your code's bugs. Add contract monitoring for the failure class it structurally can't see: the ones that return 200, and the ones whose cause lives in someone else's deployment.