Is Postmark Down?

No — Postmark is up

Reachable from all 8 checked regions

Average response time: 777ms

Last checked 4 hours ago · checks run every 6 hours

Official status page: https://status.postmarkapp.com

Postmark uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

760ms

Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 12 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

12-day clean streak

Jul 26 Today

No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams

617ms

DNS 36ms TCP 2ms TLS 9ms TTFB 610ms

lax

450ms

DNS 16ms TCP 1ms TLS 9ms TTFB 446ms

lhr

547ms

DNS 16ms TCP 2ms TLS 8ms TTFB 542ms

nrt

1150ms

DNS 115ms TCP 1ms TLS 8ms TTFB 1144ms

ord

190ms

DNS 39ms TCP 2ms TLS 10ms TTFB 185ms

sin

1621ms

DNS 181ms TCP 1ms TLS 7ms TTFB 1615ms

sjc

440ms

DNS 14ms TCP 4ms TLS 11ms TTFB 434ms

syd

1388ms

DNS 48ms TCP 1ms TLS 6ms TTFB 1376ms

yyz

266ms

DNS 94ms TCP 1ms TLS 7ms TTFB 260ms

What Postmark does

Postmark is a transactional email service used for the messages an application must deliver quickly: password resets, receipts and account notifications. Applications send through its API or SMTP. Its status page is deliberately simple, reporting Postmark as a single service rather than breaking it into components, and publishing scheduled infrastructure maintenance windows in advance.

What an outage looks like

Send calls fail or time out at the API or SMTP boundary, so the application learns immediately that the message did not leave. Password resets and one-time codes stop reaching users, which surfaces as a login support queue rather than as an email problem. Webhooks for delivery, bounce and open events stop arriving at your endpoint.

What to do about it

Check status.postmarkapp.com, which reports Postmark as a single service, so it will tell you whether there is an incident but not which part is affected. Your own send logs are the better diagnostic: a message that returned an error never entered Postmark and can be retried, while one that was accepted should not be re-sent. Scheduled maintenance is announced on the same page.

Is it down for everyone, or just you?

If this page says Postmark is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

Postmark outage FAQ

Is Postmark down or is my sending code failing?

Check status.postmarkapp.com first, then your own logs. Because the status page reports Postmark as a single service without per-component detail, it confirms an incident but not its scope. An authentication or payload error returns a specific message from the API and is yours to fix; a timeout or a server error during a reported incident is not.

Should I retry messages that failed during an outage?

Retry only the sends that returned an error, since those never entered Postmark. A message that was accepted is already queued, and re-sending it delivers twice, which is worse than a delayed password reset. Your application's own record of the API response at send time is what separates the two cases.

Why did my webhooks stop arriving?

Postmark posts delivery, bounce and open events to an endpoint you control, so the failure can be at either end. During an incident, event delivery can lag or stop while sending continues. Before changing your webhook configuration, confirm your own endpoint is reachable and returning a success status, because a receiving endpoint that keeps erroring is a common cause of missing events.

Does scheduled maintenance mean downtime?

Not necessarily. Postmark announces infrastructure maintenance windows on the same status page in advance, and a window is a period of higher risk rather than a guaranteed outage. If your application sends time-critical mail, the announced window is worth knowing about so an unusual failure during it can be attributed quickly rather than investigated from scratch.

How we measure this

We request Postmark's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
Response times average only the regions that actually served the page, so a timeout never inflates the number.
Where Postmark publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Postmark goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required