Status
Service status: All checks passing.
Checked at 22:57 BST on 13 October 2026, and every 10 minutes before that, from outside the service by a monitor on a different provider. If this website were down too, the monitor's own page would still be up: it shares a provider with neither.
-
mcp.mailbox-mcp.com/healthzok -
mcp.mailbox-mcp.com/db/healthzok
The last 90 days, oldest first and today last. A day takes the worst thing that happened in it.
- No failures
- Degraded
- Down
- No data yet
31 of 90 days recorded: 30 with no failures, 0 degraded, 1 down.
Incidents in the last 90 days, newest first.
-
3 hours 30 minutes
on 23 September, from 05:20 BST to 08:50 BST
Service unavailable overnight
Between about 04:30 and 08:50 BST on 23 September 2026 the service was unavailable. Our monitor first saw it at 05:20. An overnight security update stalled on our systems, and the restart that followed could not complete. Service was restored at 08:50 and no customer data was lost.
We traced the cause, changed how updates run across our systems, and added an automatic check that recovers them within a couple of minutes if anything like this happens again.
An incident opens on the check at which the monitor has seen enough consecutive failures to alert us, and closes on the first check that gets an answer. A day in the strip turns red only when the service was out for at least 10 minutes, which is 2 failed checks in a row. A single failed check that recovers at once is a blip and marks nothing. A degraded run is never an incident: the service was answering.
Method
What the monitor checks
Two endpoints, every 10 minutes
A small program on Cloudflare checks the service every 10 minutes, from outside it. Cloudflare was chosen because it is neither the provider that runs the service nor the one that serves this website.
It requests the service's 2 public health endpoints, one for each of the 2 servers customers can reach. The second is the one every customer connection runs through, and it also checks its database.
Each answers in status words and nothing else: no filenames, counts or mailbox addresses. Both are the same addresses anybody can request.
Down, and degraded
Down means the monitor couldn't get a healthy answer: an endpoint didn't answer, or answered with an error. A day is recorded as down only when that lasted at least 10 minutes, which is 2 failed checks in a row. A lone failed check is a blip, not an outage.
Degraded means the service answered but reported a stale self-check, such as last night's backup marker being older than it should be. We're alerted, and nothing customer-facing is off.
The monitor alerts on both and records them apart, because a backup that quietly stopped is exactly the kind of thing a status page is for. The headline gives the same 2 words for right now, and says since when if the service is degraded as you read it.
No service level agreement, and what there is instead
The terms say so plainly. What there is instead:
- this page, drawn from the monitor's own 90-day record with a 60-second cache in front of it, and never from the service;
- an alert to the person who runs the service when the monitor sees consecutive failures;
- the monitor's own page, the fallback if this website is the thing that is down;
- a page for IT and security teams that says where the service runs, what is backed up and how an incident is notified.
mcp.mailbox-mcp.com/healthz
200 ms
- Database
- not configured
- Nightly backup
- ok
- Off-site copy
- ok
- Retention job
- ok
- Clean checkout
- ok
mcp.mailbox-mcp.com/db/healthz
200 ms
- Database
- ok
- Nightly backup
- ok
- Off-site copy
- ok
- Retention job
- ok
- Clean checkout
- ok