Skip to main content
Loops logo

Is Loops Down?

No — Loops is up

Reachable from all 8 checked regions

Average response time: 587ms

Last checked · checks run every 6 hours

Official status page: https://status.loops.so

Loops uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
256ms
Avg response, 30 days

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

30-day history

11-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: no data
Aug 27: no data
Aug 28: no data
Aug 29: no data
Aug 30: no data
Aug 31: no data
Sep 1: no data
Sep 2: no data
Sep 3: no data
Sep 4: no data
Sep 5: no data
Sep 6: no data
Sep 7: no data
Sep 8: no data
Sep 9: no data
Sep 10: 100.00% uptime, 16 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 32 checks
Sep 13: 100.00% uptime, 32 checks
Sep 14: 100.00% uptime, 31 checks
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, 24 checks
Aug 22 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.

lax
1167ms
DNS 768ms TCP 162ms TLS 13ms TTFB 1133ms
lhr
159ms
DNS 10ms TCP 2ms TLS 13ms TTFB 128ms
nrt
127ms
DNS 8ms TCP 1ms TLS 22ms TTFB 96ms
ord
945ms
DNS 763ms TCP 2ms TLS 13ms TTFB 916ms
sin
783ms
DNS 360ms TCP 36ms TLS 80ms TTFB 573ms
sjc
1200ms
DNS 1001ms TCP 2ms TLS 12ms TTFB 1171ms
syd
87ms
DNS 12ms TCP 1ms TLS 15ms TTFB 59ms
yyz
228ms
DNS 95ms TCP 1ms TLS 12ms TTFB 202ms

What Loops does

Loops is an email platform aimed at software companies, covering both the automated messages a product sends to one person and the campaigns a team sends to a list. Applications connect through an API or an SMTP relay, and Loops reports delivery events back by webhook, so it sits on the path of password resets and receipts as well as newsletters.

What an outage looks like

Password resets, sign-in links and receipts stop arriving, which surfaces as users unable to get into your product rather than as an email problem. Campaigns may fail to send or stall part way through a list. Applications calling the API receive errors or timeouts, and delivery webhooks stop arriving, so your own records of who received what quietly stop updating.

What to do about it

Read status.loops.so, which reports Email Sending, Loops, Campaigns, Transactional, API, App, SMTP Relay and Webhooks as separate components. Match the symptom to the row. If only Campaigns is affected, transactional mail such as password resets continues, which is the half that blocks users. Do not resend a campaign that reported a partial send until you can confirm who already received it.

Is it down for everyone, or just you?

If this page says Loops 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 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

Resend
Resend
Postmark
Postmark
Mailgun
Mailgun
MailerLite
MailerLite

Loops outage FAQ

Users cannot log in because reset emails are not arriving. Is that a Loops outage?
It can be, and it is the failure worth spotting quickly because it looks like an authentication bug rather than an email one. Loops reports Transactional as a component separate from Campaigns, so password resets and sign-in links can fail while marketing sends normally. Check the Transactional and Email Sending rows on status.loops.so before you start investigating your own login flow.
Will emails sent during a Loops outage eventually arrive?
Some will and some will not, depending on where the failure sat. A message accepted by Loops before a delivery problem is generally retried onward, while a send attempt that never reached the API was never queued at all. Loops does not publish retry behaviour for every component, so check your own send logs for calls that returned an error and treat those specific messages as unsent.
My send looks successful but nothing was delivered. What happened?
That pattern usually means the interface accepted the instruction while the layer that actually sends did not complete it. Loops lists Email Sending as a component separate from App and API for this reason. Resending immediately is what creates duplicates, so confirm the true state on the status page and in your delivery records before sending again, particularly for a campaign that may have partially gone out.
My delivery webhooks stopped. Is my data now wrong?
Probably incomplete rather than wrong. Webhooks is its own component, so delivery, open and click events can stop reaching your application while the mail itself sends normally. Your own database then shows fewer delivered messages than were actually delivered. Treat reporting from the incident window as understated, and check with Loops before you reconcile records or re-trigger anything based on missing events.
Is it Loops or my SMTP configuration?
Compare scope and the path. Loops reports SMTP Relay separately from API, so a failure on only one of those points at the integration path rather than at sending as a whole. A wrong credential or a blocked port affects one application and returns a specific authentication or connection error. Check which component is affected before changing SMTP settings during an incident.

How we measure this

  • We request Loops'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 Loops 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 Loops goes down

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

Start Free Monitoring
Free plan available No credit card required