Loops status

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.

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.