sharper drift diffs
Grouping related field changes into a single readable diff, tied to the deploy that introduced them.
$ zivvo about --why
we tell you when your api is broken.
That is the whole job. Zivvo checks your REST and GraphQL endpoints from more than thirty regions, notices what changed, and sends the right engineer the evidence. This page explains why we think that job deserves a product of its own.
01 / the problem
the status page was green. the customer was not.
Most outages do not announce themselves. A response that used to take 120 milliseconds takes 900. A field that was a number becomes an object after a Tuesday deploy. A payment call fails in two regions and succeeds in eight, so the average looks fine and the dashboard stays calm.
Somebody notices eventually, and it is usually the person least able to fix it: a customer, writing in politely. By the time the ticket reaches an engineer, the useful evidence has scrolled out of the logs and the morning is spent finding a cause that was knowable at 09:47.
Zivvo was built for that gap. Not to produce more graphs, but to shorten the distance between something changing and the right person holding the proof of what changed.
02 / principles
four convictions we build against
Each one has turned down a feature at some point. That is how you know it is a principle and not a slogan.
- P.01
an alert is a claim; attach the proof
Every alert carries a request trace: the headers, the response body and the span that stalled. If we cannot show why we woke someone, we should not have woken them.
- P.02
one set of checks, one story
What pages you, what the status page shows and what the diff says all read from the same checks. A status page that can disagree with the pager is a liability, so ours cannot.
- P.03
the outlier matters more than the average
A mean hides the one region that is struggling. Zivvo sets every zone against the median and names the odd one out, because that is where customers are actually hurting.
- P.04
quiet by default, loud when it counts
Routing follows your on-call schedule, and a change is grouped into a single incident rather than forty messages. Silence should mean something, so noise has to be earned.
03 / how it is built
checks first, everything else second
The check runner is the heart of Zivvo and the part we are most careful with. Probes run in more than thirty regions on an interval you choose, from ten seconds to five minutes, and each reply is compared against the response shape learned for that endpoint.
Support works the same way. Questions go to a single inbox and are answered by the people who maintain the runner, so a bug report reaches the code in one hop.
- ProtocolsREST and GraphQL, imported from OpenAPI or a schema
- Cadence5 minutes on Hobby, 1 minute on Team, 10 seconds on Scale
- EvidenceA trace snapshot on every alert, on every plan
- Supportcontact@zivvoapi.com, read by the engineers
04 / where it is going
the next things on the bench
A direction, not a promise of dates. We would rather ship one of these properly than announce all three.
deeper flow assertions
More ways to assert on a multi-step journey, including time budgets per step and reuse of values between calls.
a longer memory
Longer retention for traces and uptime history, so a slow regression in March can still be compared with today.
$ zivvo init
hear it first. the rest is detail.
Pick the check interval you cannot afford to miss. Every plan includes schema drift detection and a request trace on every alert.
Get started