# Loops status

> Is Loops down? Live status, uptime history, and per-region response times for the Loops email platform from our own probes every 2 minutes.

Published: 2026-08-31 | Canonical: https://yoping.me/status/loops

## How we check Loops

We watch app.loops.so 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 application host that serves both the dashboard and the API your product posts events to, and pin the response an anonymous request receives. Whether a message reaches an inbox depends on your sending domain and the receiving provider, which no external probe can measure and no status page can answer.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/loops. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## What is Loops?

Loops sends product email: onboarding sequences, lifecycle messages,
announcements, and the transactional mail a product emits as people use
it. Its distinguishing choice is to organise sending around events from
your application rather than around campaigns and lists, so a message
goes out because a user did something, not because someone scheduled a
send on Tuesday.

That design decides what an incident, and what an apparent incident,
looks like. The most common report is not that Loops is unavailable but
that an email did not arrive, and the great majority of those are working
as configured. Events only produce mail if a loop is listening for that
event, the contact matches the audience, and no rule has excluded them.
Unsubscribes, filters that do not match, and messages already sent all
suppress mail silently and correctly. The contact's timeline records what
happened to them specifically, which answers the question far better than
any status page can.

The distinction between accepted and delivered applies here as it does to
every sending platform. Acceptance means the message entered the system.
Whether it reaches an inbox depends on your sending domain's
authentication records, the reputation attached to it, the content, and
the receiving provider's filtering that week. None of that is visible to
an outside monitor, none of it appears on a status page, and all of it
can go wrong while every system involved reports itself healthy. A DNS
change made during unrelated work is a remarkably common cause of mail
quietly failing.

For transactional messages, where the email is part of a flow rather than
beside it, the architectural advice is the same as for any provider.
Sending inside a web request makes the provider a hard dependency of that
request, so an outage becomes a signup form that errors. Sending through
a background queue with retries makes the same outage a delay that
resolves itself, and the difference is a few hours of work that pays for
itself the first time it matters.

The last thing worth doing after any incident is checking what did not
happen. Event-driven sending means the trigger has passed, and a message
that failed to send during an outage will not be retried simply because
the platform recovered. Reconciling the events your application emitted
against the messages that actually went out is the way to find the gap,
and it is worth doing before a customer finds it for you.

## Frequently asked questions

### Is Loops down right now?

Check the board above; it reflects our own probes against Loops from all five of our regions, refreshed every couple of minutes and confirmed across two regions before this page would call it down.

### Loops accepted my event but no email was sent. Is that a fault?

Usually not, and it is the most common Loops confusion. Sending an event only triggers mail if a loop is configured to listen for it, the contact is eligible, and no other rule has excluded them. A contact who unsubscribed, who does not match the audience filter, or who already received that message will be skipped by design, and the contact's own timeline shows which of those applied.

### Why did my emails start landing in spam?

Because deliverability is a reputation problem rather than an availability one. A sending domain without correct SPF, DKIM and DMARC records, a domain sending in volume before it has any history, or a list with a high bounce rate will all push mail towards spam folders while the platform is completely healthy. Check the authentication records on your sending domain first.

### Do transactional emails stop if Loops is unavailable?

Yes, anything that depends on the API being reachable stops, which is why sending should not sit in the request path. If your application waits for the API call to return before responding to a user, an outage becomes a broken signup or checkout. Queueing sends in a background job with retries turns the same outage into a delay nobody notices.

### How is this different from Loops' own status page?

Theirs reports what the Loops team has confirmed and chosen to publish. Ours reports what our own probes see from outside their infrastructure, on a fixed schedule, whether or not anyone has written an update - a rougher signal that shows up sooner, not a replacement for theirs.