Monitoring the contract, not the server
After fifteen years of operations work, I have a strong opinion about which kind of monitoring tells you something useful and which kind tells you something you already know.
why this is the post that started DevFlow
Every observability platform I've used over the past decade has been very good at telling me a server is overheated, a queue is backing up, or a CPU is pegged. They've been very bad at telling me my customers can't actually use my API.
The reason is that infrastructure metrics are not contract metrics. The CPU is fine; the assertions on the JSON the user receives back are not.
the smallest example
Two services. The dependency returns:
{ "status": "ok", "balance_cents": 12300, "currency": "USD" }A patch ships that adds a field:
{ "status": "ok", "balance_cents": 12300, "currency": "USD", "balance_pending_cents": 0 }Backwards-compatible. CPU fine. Memory fine. Status code 200.
Three of your downstream services break because they were using a JSON-Schema with additionalProperties: false.
Your monitoring stack has nothing to say about this.
what we built instead
DevFlow Watch starts from the request. The monitor is the contract. We assert on shape, on latency, and on the small set of fields you actually depend on.
When the contract changes, the contract owner finds out — not the customer.
what this isn't
This is not a replacement for APM. It's not a replacement for Datadog or New Relic. It's the layer above. We deliberately do not run agents on your servers. We deliberately do not read logs.
We watch what your customers' code watches: a request, a response, a clock.
That's enough. It's a smaller, sharper question to answer well, and there are eight years of unsolved gnarly problems in answering it.
come build with us
We're hiring engineers in San Francisco and Lisbon. If "the contract is the unit of monitoring" sounds like an obvious thing to spend a career on, we'd love to talk.
— Marcus