- Operational
API
Accepting sends and serving the REST API.
- Operational
SMTP submission
Accepting mail submitted over SMTP.
- Operational
Outbound delivery
Delivering accepted mail to recipient mail servers.
- Operational
Inbound mail
Receiving bounces, complaints and replies.
- Operational
Event webhooks
Posting delivery events to your endpoints.
- Operational
- Working normally, and checked within the last few seconds.
- Degraded
- Still working, but not properly. Usually mail being accepted faster than it is going out — nothing is lost, it is arriving late.
- Outage
- Not working. Mail already accepted stays queued and is delivered on recovery.
- Unknown
- We cannot currently tell. Shown as its own state rather than guessed at in either direction.
Where these states come from
Nobody at Posthaste can mark a component green, and there is no page in our admin panel for doing it. A status page somebody has to remember to update is worse than no status page at all, because it is confidently wrong at exactly the moment you are relying on it — so this one is wired to the machinery instead.
- The mail servers report themselves. Each one writes a timestamp as a side effect of doing its work. A server that has stopped, crashed, deadlocked or lost its connection to our database cannot write that timestamp, so its entry here goes stale and turns red on its own within about ninety seconds.
- The API is checked by using it. Its state comes from a real query against the store it needs in order to accept your mail, not from asking the process whether it feels well. A server can be perfectly capable of answering a health check and completely incapable of accepting a send.
- Late is a state of its own. The worst outage a transactional email platform can have is the quiet one: everything accepting mail, nothing delivering it. Every process looks alive and every check passes. We watch how long the oldest message that is due to go out has been waiting, and mark delivery degraded before anybody has to notice for us.
What this page will not tell you
It is public, so it deliberately says less than we know. There are no server names, versions, error messages or queue sizes here — a backlog figure would describe how much mail our customers send, which is theirs and not ours to publish, and the rest is only useful to somebody attacking us. What is left is what you can act on: which parts of the service are working, and how late your mail is likely to be.
Something wrong that is not shown here?
Delivery to one particular recipient domain can fail while everything on this page is green — receivers defer and block for their own reasons, and that is a conversation about a specific message. The waybill for any message in your dashboard shows every attempt, every response and the reason for each. If it does not explain what you are seeing, write to [email protected] or read the deliverability notes.