What Happens When Rythm Goes Down? The Fail-Open Promise

Every SaaS product that touches email has to answer one question honestly. What happens to my email when your service has a problem?

The bad answers are common. “Emails queue and retry” means during an outage your mail is stuck somewhere. “Filters fail closed for safety” means during an outage legitimate emails get blocked. “Degraded mode” usually means the service is half-working and nobody knows exactly what that means for the email that is currently in flight.

Rythm’s answer is blunt. When anything in the Rythm filter system fails, your email delivers to your inbox normally. The filter’s default failure mode is to get out of the way.

This is not a policy promise. It is an architectural property, baked into how the system is built. Here is what it means and how it works.

Fail-Open Defined

In security engineering, filters have two failure modes. Fail-closed means a failure causes the filter to stop letting anything through (nothing passes unless the filter explicitly approves it). Fail-open means a failure causes the filter to stop enforcing (everything passes unless the filter explicitly denies it).

Both have tradeoffs. Fail-closed filters are appropriate when the downside of letting something bad through is catastrophic and the downside of blocking something good is trivial. Firewalls protecting classified networks are fail-closed. Nuclear plant safety systems are fail-closed.

Fail-open filters are appropriate when the downside of blocking something good is high and the downside of letting something marginal through is manageable. Email is fail-open. Losing an email from a real person because your filter had a glitch is worse than receiving an email you would have filtered. Rythm is architected accordingly.

What Fail-Open Looks Like in Practice

There are three parts of the Rythm system where failure could, in principle, affect your email. The architecture handles each as follows.

The filter processing layer. This is where Rythm decides whether an incoming email is from a known or unknown sender, and whether a cover charge has been paid. If this layer fails (a Lambda timing out, a data store being unreachable, a dependency being down), the email is delivered to your inbox with no RYTHM label applied. You see the email in your inbox. The Rythm labels just do not appear. When the filter recovers, it resumes processing incoming email normally.

The notification layer. This is where Rythm sends the verification email back to an unknown sender. If this layer fails, the sender does not receive the verification prompt, but their original email is still in your inbox (or your separate folder, if the filter processed before the notification failed). In other words, the notification failure might mean a sender does not see the cover charge message, but it does not delay or lose any email that was destined for you.

The payment settlement layer. This is where paid emails get moved into your inbox and their associated cover charge settles to your wallet. If this layer has a problem, the sender’s payment has already cleared peer-to-peer (the money settled to your wallet regardless) and the email itself is in your separate folder. You rescue it with one drag. The failure affects the automation, not the economics or the recoverability.

In every case, the worst outcome is that Rythm temporarily behaves like it is turned off. Your inbox works the way it did before you installed Rythm. No email is lost, no email is delayed, no email is bounced.

What an Outage Would Look Like

Outages are rare, and most are short enough that the system recovers gracefully before anyone notices. When something does affect a user visibly, the symptoms vary by what is failing. In the unlikely case you do see something:

• New unknown-sender emails would appear in your inbox without the usual RYTHM: PAID or RYTHM: REJECTED label.
• You may see a small informational banner in your dashboard noting an active incident.
• The verification email sent to strangers may be briefly delayed or, in unusual cases, not sent during a full notification-layer outage.

What you will never see, regardless of what is failing on our end:

• An email lost to an outage.
• An email held in a queue that cannot be flushed.
• A cover charge payment that was sent but not received.
• An inability to read or reply to historical email that was already in your account.

The dashboard also publishes a status page. Major incidents are uncommon, and when they happen subscribers get a direct notification.

Why Fail-Open Was a Deliberate Decision

The alternative would be fail-closed: if Rythm has a problem, hold the email until we recover. This is how some enterprise email security tools work. The logic is that if a filter is broken, letting unfiltered email through might allow a phishing email to land unfiltered.

Rythm rejects this logic for a specific reason. A filter outage that holds email creates two classes of harm. First, every legitimate email is delayed until the filter recovers, which can take hours. Second, the harm concentrates on the user, not the attacker. The attacker does not care whether their email arrives with a two-hour delay; the legitimate business correspondent, lawyer, doctor, family member, or prospect does.

The asymmetry is severe. In a population of 1,000 inbound emails, perhaps 50 would have been filtered correctly by Rythm and perhaps 5 of those 50 were actual attack attempts. The other 995 are legitimate email. Holding 1,000 emails for hours to prevent 5 bad emails is a bad trade.

Rythm is fail-open because the cost of a missed legitimate email is always higher than the cost of a cold outreach email slipping through during an outage. That trade is not even close.

Architecture Properties That Enable This

Fail-open is not something you can add after the fact. It has to be designed in. The relevant architectural choices:

• Rythm sits downstream of delivery. Incoming emails land in your Gmail or Outlook inbox through normal provider delivery first. Rythm then processes them after the fact and applies labels. This means a Rythm failure cannot block delivery, because delivery has already happened.
• No in-line proxying. Rythm does not sit between your email provider and you. Your inbox receives email directly from Google or Microsoft. Rythm operates on the inbox through OAuth and provider APIs, reading and labeling messages rather than gating their arrival.
• Stateless processing where possible. Most of the filter decision is made from the current email and the current guest list. There is no long-running queue that can get stuck.
• Payment flow is peer-to-peer. Cover charge payments settle directly from sender to your own Lightning wallet via a public Cashu mint. Rythm is not a custodial node in the payment flow that could be a single point of failure.

These choices mean the things that break in a distributed system (service dependencies, queues, database connections, API rate limits) can all fail without breaking the property users care most about: their email arriving at their inbox.

The Trust Argument

Fail-open is the engineering commitment behind the bigger trust argument. You are giving Rythm OAuth access to your inbox. That access is meaningful and reversible, but it is real. You want assurance that even if the startup you are trusting has a bad day, your email is fine.

The answer to that assurance has to be structural. A promise (“we will work hard to stay up”) is worth very little. An architecture (“our failure mode is that your email delivers normally”) is worth a lot, because it does not depend on anyone’s diligence. It is a property of the system.

The same architecture is what makes cancellation safe. The same architecture is what makes the non-custodial claim real. The same architecture is what lets us say, truthfully, that losing an email to Rythm is not a thing that happens.

Summary

Outages are rare, and the system is designed to recover gracefully when they happen. But on the rare day Rythm has a problem, your email delivers normally regardless. That is the entire promise. The architecture makes it true.