Service status answers one question: is this us or is this you. The status endpoint is unauthenticated and returns fast, so you can check it from a handler without a key.
We treat two things as incidents. The API being unavailable or erroring, and verification throughput dropping far enough that batches queue rather than run. Both get an entry with a start time, updates while it is open, and a plain explanation when it closes.
A third thing is not an incident, and this is the one worth understanding. When a single large mail host throttles or blocks probe traffic, your unknown rate for that host rises and everything else runs normally. That is the network behaving as the network does. It shows on the status page as a note, because you deserve to know why a batch looks different today, but nothing is broken on our side.
curl https://api.zapbounce.com/v1/status{
"status": "operational",
"api": "operational",
"verification": "operational",
"notes": [],
"checked_at": "2026-09-18T10:31:00Z"
}Reference
| Value | Meaning | What you should do |
|---|---|---|
| operational | Everything normal. | Nothing. |
| degraded | Slower than usual, still working. | Widen timeouts, do not retry harder. |
| partial_outage | One surface is down. | Check the notes for which. |
| major_outage | The API is unavailable. | Back off and wait for the update. |
| maintenance | Planned work, announced in advance. | Nothing. Batches queue and resume. |
A 2 a.m. decision tree for your batch job
Say your nightly job starts seeing 503s. Before it retries, it calls GET /status, which needs no key. If the answer is major_outage, the job stops retrying, sleeps for a good while and checks again before it sends anything else. With degraded, it widens its timeouts and carries on at the same pace. In both cases nobody needs to be woken up.
Now a different night. Status reads operational, there are no errors, but the unknown count on your batch is double the usual. Read notes. If a note names a mail host that's throttling probes, nothing is broken on either side. Hold the unknowns and resubmit them tomorrow, since they weren't billed.
One more case: operational, and your job is getting 401s. That one is yours. Check the key before you open a ticket, and look at when it was last rotated.
Using status in a signup flow without adding a dependency
Don't call /status on every signup. You'd double your request count, and you'd make your form depend on two of our endpoints where it used to depend on one. Have your server read it once a minute and keep the answer in memory.
While the cached value isn't operational, skip the verification call, accept the signup, and queue the address for a background check later. Your visitor never sees our bad minute.
Two alerting mistakes are common. One is paging on a non-empty notes list. Notes explain odd-looking results and aren't incidents, so send them to a channel and not to a pager. The second is treating maintenance as a failure. Batches queue during planned work and resume afterwards, so a job that cancels and resubmits in that window only makes extra work for itself.
Questions developers ask
Is the status endpoint authenticated?
No. It takes no key and is safe to poll from anywhere, including a health check that has lost its credentials.
Do you post postmortems?
For anything that took the API down, yes, with what broke and what changed afterwards.
Where do I subscribe?
The hosted status page takes email and webhook subscriptions. Its URL is published at launch.