Skip to main content
Postmark logo

Is Postmark Down?

No — Postmark is up

Reachable from all 8 checked regions

Average response time: 609ms

Last checked · 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
854ms
Avg response, 30 days

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

30-day history

63-day clean streak
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 32 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 32 checks
Sep 21: 100.00% uptime, 32 checks
Sep 22: 100.00% uptime, 32 checks
Sep 23: 100.00% uptime, 32 checks
Sep 24: 100.00% uptime, 32 checks
Sep 25: 100.00% uptime, 32 checks
Sep 26: 100.00% uptime, 32 checks
Sep 27: 100.00% uptime, 32 checks
Sep 28: 100.00% uptime, 32 checks
Sep 29: 100.00% uptime, 31 checks
Sep 30: 100.00% uptime, 28 checks
Oct 1: 100.00% uptime, 31 checks
Oct 2: 100.00% uptime, 32 checks
Oct 3: 100.00% uptime, 32 checks
Oct 4: 100.00% uptime, 32 checks
Oct 5: 100.00% uptime, 32 checks
Oct 6: 100.00% uptime, 32 checks
Oct 7: 100.00% uptime, 32 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: 100.00% uptime, 32 checks
Oct 13: 100.00% uptime, 32 checks
Oct 14: no data
Sep 15 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
625ms
DNS 12ms TCP 2ms TLS 11ms TTFB 623ms
arn
820ms
DNS 51ms TCP 1ms TLS 7ms TTFB 817ms
cdg
763ms
DNS 13ms TCP 2ms TLS 10ms TTFB 759ms
dfw
362ms
DNS 45ms TCP 3ms TLS 12ms TTFB 357ms
ewr
312ms
DNS 130ms TCP 1ms TLS 10ms TTFB 309ms
fra
796ms
DNS 32ms TCP 9ms TLS 18ms TTFB 784ms
gru
988ms
DNS 123ms TCP 2ms TLS 20ms TTFB 979ms
yyz
208ms
DNS 64ms TCP 2ms TLS 12ms TTFB 205ms

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 up to 17 cities across three 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 — the most recent check ran from 8 of them.
  • 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 up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required