Postmark status

How we check Postmark

We watch api.postmarkapp.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the API host your application posts messages to and pin the exact response an anonymous request receives, rather than assuming a 2xx means health. Postmark's own status page and marketing site are served elsewhere, so neither tells you whether the sending API is currently accepting your traffic.

What is Postmark?

Postmark sends transactional email, and it is deliberately narrow about what that means. Receipts, password resets, confirmations, invitations, and alerts are its subject, and marketing campaigns are explicitly not. That focus is the product: by refusing bulk mail, the service keeps the reputation of its sending infrastructure high enough that the messages that genuinely need to arrive quickly usually do.

That design decision shapes what an incident looks like. Transactional email sits inside a user-facing flow rather than beside it. Nobody notices a delayed newsletter, but a password reset that has not arrived after two minutes produces a support ticket, and a signup confirmation that never lands loses the customer entirely. The cost of an email provider being unavailable is therefore concentrated in the moments that matter most to the business, which is a good argument for not putting the send in the middle of a web request.

That is the most useful piece of engineering advice about any email provider, Postmark included. When an application sends mail synchronously, waiting for the API call to return before responding to the user, a provider outage becomes a broken signup form. When it sends through a background queue with retries, the same outage becomes a delay that resolves itself once the provider recovers, with no user ever seeing an error. The difference is a few hours of work and it converts an entire class of third-party failure into something survivable.

Message streams are the Postmark-specific detail worth understanding. Transactional and broadcast mail are separated so that a large send cannot queue behind itself and delay a password reset, and messages are routed by the stream they are sent on. Mail configured on the wrong stream can be delayed or rejected in ways that look like an outage but are entirely local to your configuration, and the errors do not obviously point at the cause.

The other frequent source of self-inflicted failure is sender verification. Postmark will refuse to send from an address whose domain or signature has not been verified, and a domain whose DKIM record was edited or expired during unrelated infrastructure work will start rejecting sends with a validation error rather than a delivery failure. Because the message never enters the queue, nothing appears in delivery statistics, and the first sign is often a quiet drop in email volume that nobody has an alert for.

Frequently asked questions

Is Postmark down right now?

Check the board above; it reflects our own probes against Postmark's API from all five of our regions, refreshed every couple of minutes. A single region seeing a failure is not enough for this page to call it down.

Postmark accepted my email but the recipient never got it. What happened?

Acceptance and delivery are different events, and Postmark's own activity log is where the answer lives. A message can be accepted and then bounce, be suppressed because that address bounced before, or be filtered by the recipient's provider. Postmark keeps a per-message record with the outcome and the reason, which resolves this far faster than any status page.

Why are my transactional emails suddenly slower to arrive?

Usually because of queueing somewhere in the path rather than an outage. Postmark separates transactional and broadcast streams precisely so that bulk sending cannot delay a password reset, so a delay affecting only one stream points at that stream's configuration or volume. If the board above shows the API responding normally and delays persist, check which message stream the affected mail is using.

Does Postmark going down break my application?

It breaks anything that waits on an email being sent, which is more of your application than you might expect. A signup flow that blocks on a confirmation message, a password reset, or a checkout that waits for a receipt will all stall or error, while the rest of the product keeps working. Queueing email sends in a background job rather than in the request path is what turns a provider outage into a delay instead of a failure.

I am getting 401 or 422 errors from the API. Is that an outage?

No, both mean Postmark answered you correctly. A 401 points at a server token that was rotated or belongs to a different server than the one you are addressing, and a 422 points at the request itself, most often a from address that is not on a verified sender signature or domain. Neither is a platform problem and neither will appear on a status page.