All systems operational
Temp Postal status — delivery transparency, published not promised.
A temp-mail service is only as good as its delivery. This page shows how we measure it, what the current state is, and every incident we have ever recorded. If a number appears here, it was measured. If it wasn't measured, we say so.
Current status
| Component | Status | Detail | Last verified |
|---|---|---|---|
| Inbox generation | Operational | Temporary addresses generate on page load across receiving domains. | Oct 6, 2026 · manual verification |
| Message delivery | Operational | Inbound mail is parsed and pushed to inboxes in real time. | Oct 6, 2026 · manual verification |
| API | Operational | REST endpoints and webhooks responding normally. | Oct 6, 2026 · manual verification |
| Dashboard | Operational | Account dashboard, inbox management, and billing status reachable. | Oct 6, 2026 · manual verification |
How delivery is measured
Temp Postal receives mail through its own inbound infrastructure across 20+ rotating domains. To know — not guess — whether that infrastructure is healthy, we run synthetic probe inboxes: real inboxes on each receiving domain, created the same way yours are, that exist only to receive test messages we send on a schedule.
- Send. A test message is dispatched to a probe inbox from an external sender, exercising the full path: DNS, receiving servers, parsing, storage.
- Observe. The probe watches for the message the same way your browser does — over the live inbox connection. If it appears and is readable, the probe passes.
- Classify. On-time arrival is delivered. Arrival outside the expected window is delayed and flagged. No arrival is failed — repeated failures on a domain open an incident below.
- Publish. Aggregate results land in the status table above. We never publish a metric we didn't run, and we never backfill history.
Probing measures our infrastructure. Whether a third-party site accepts a disposable address is that site's decision — some block disposable domains outright — and no status page can change that. For blocklist-sensitive signups, Business plans can receive on a custom domain.
Incident history
Every recorded incident, newest first. Entries are written when an incident is declared and updated until resolved — never deleted or rewritten afterward.
No incidents recorded since monitoring began (October 6, 2026). When the first incident occurs, it will appear here with the affected component, what broke, what was done, and the resolution time.
Get notified when something breaks
Incident notifications by email. No marketing, no newsletter — only a message when status changes, and one when it's fixed.
Subscribe to status updatesEmail contact@temppostal.com with the subject “Subscribe: status updates” — a human confirms every signup.
Status & delivery FAQ
How Temp Postal's delivery monitoring works and what this page does and doesn't claim.
How does Temp Postal measure delivery?
We run synthetic probe inboxes on each of our receiving domains and send test messages through them on a schedule. A probe counts as delivered when the message is received by our inbound infrastructure, parsed, and visible in the probe inbox. This page publishes the results; the methodology is fixed so the numbers stay comparable over time.
What counts as delivered, delayed, or failed?
Delivered means the message arrived and was readable in the inbox. Delayed means it arrived outside the expected window and is flagged for investigation. Failed means it never arrived; repeated failures on a domain trigger an incident entry below and remediation work on that domain's receiving path.
Why is there no 90-day uptime history?
Because we will not invent one. Public monitoring on this page began on October 6, 2026, and the table above is the initial baseline. History accumulates from here, and the first full 90-day window will be published once it genuinely exists. Any status page showing history it never measured is marketing, not transparency.
Do you monitor all receiving domains?
Yes. Probes run against every active receiving domain, not a sample. If a single domain degrades while others are healthy, it is reported as a partial incident with the affected domain named, so you can choose a different domain for time-sensitive signups.
What happens when there is an incident?
The affected component row above changes status, an entry is added to the incident history with what broke, what we did, and when it resolved, and subscribers are notified by email. Incident entries are never deleted or rewritten after the fact.
How do I get notified about incidents?
Email contact@temppostal.com with the subject line 'Subscribe: status updates' and we will add you to the incident notification list. Automated self-serve subscriptions are on the roadmap; until then a human confirms every signup.