A brief hiccup no longer disconnects your mailbox

A single failed connection no longer marks a mailbox as broken. Short interruptions are tolerated, and the status only changes when a mailbox has genuinely stopped working.

What changed

Mail providers are not perfectly available. A connection attempt fails occasionally for reasons that have nothing to do with your account: a moment of maintenance, a slow response, a rate limit that clears in a minute.

The product treated any failure as a real one. One timeout was enough to mark the mailbox as broken, and marking it broken stopped the campaigns that used it.

So a thirty second interruption at a provider produced hours of stopped sending, because nothing resumed until somebody noticed and reconnected. The reconnection almost always worked immediately, which is the clearest sign the mailbox had never actually been broken.

Now a mailbox has to fail repeatedly over a period before its status changes. One failure is retried. A pattern of failures is a real problem and is reported as one.

Why it matters

The cost was the recovery, not the outage. Providers recover in seconds. The product did not, because it needed a person to notice and act.

That turned a brief blip into a stopped campaign for however long it took someone to look, which on a weekend could be two days.

There was a second cost that was harder to see. Frequent false alarms teach people to ignore alerts. If a mailbox reports broken twice a week and reconnects fine every time, the eventual real failure gets the same shrug as the false ones.

How to use it

Nothing to configure. Tolerance applies automatically to every connector.

A mailbox showing as failing now means it has failed consistently, not once. It is worth acting on.

Sending pauses briefly during a transient failure and resumes on its own when the provider recovers. You will usually not notice it happened.

What counts as transient

A timeout. The provider did not respond in time, which usually means it was busy rather than unavailable.

A temporary rejection. Providers rate limit, and a rate limited connection is a working connection being asked to wait.

A brief authentication failure that immediately succeeds afterwards. These happen during maintenance on the provider's side and do not mean the credentials are wrong.

What still reports a failure

Repeated authentication failures. Credentials that fail consistently are wrong, whether expired, revoked, or changed.

A mailbox that cannot be reached at all over a sustained period. At that point the cause no longer matters, because the practical effect is the same.

A provider explicitly refusing the connection for policy reasons. That does not clear with time and needs the account settings changed.

The trade-off

Tolerating failures means a real problem takes slightly longer to appear. That delay is the price of not raising an alarm every time a provider takes an extra second to answer.

It is the right trade because of what each mistake costs. Reporting a working mailbox as broken stops sending immediately and needs a person to undo it. Taking a few extra minutes to confirm a genuine failure costs a few minutes of sending, and the mailbox was not sending anyway.

The threshold sits where the great majority of provider interruptions have already resolved, so a genuine failure still surfaces quickly.

What this looked like before

The pattern was recognisable once you had seen it twice. A mailbox reports broken. Somebody reconnects it. It reconnects immediately with no change to any setting, and works fine for a week until it happens again.

An immediate successful reconnection is the tell. It means the credentials were correct the whole time and nothing about the mailbox had actually changed, so whatever was reported as broken was never broken.

The reconnection was not fixing anything. It was clearing a status that should not have been set.

The second cost of false alarms

Stopped sending was the visible cost. The quieter one was what repeated false alarms did to how seriously anyone treated the alerts.

An alert that is wrong most of the time gets ignored, and it should be, because acting on it wastes more time than it saves. The trouble is that ignoring it becomes a habit, and the habit persists through the one occasion the alert is right.

Fewer alerts that are almost always real is a better arrangement than more alerts that are usually noise, even though it means hearing about problems slightly later.

When a mailbox does fail properly

The status changes, the reason names the cause, and it stays until the cause is dealt with. It does not clear itself, because a genuine failure does not resolve on its own and a status that flickers back to healthy would be worse than useless.

Campaigns using that mailbox show the blocked reason, so the failure is visible from the campaign as well as from the connector list.

Where the threshold sits

The tolerance covers a short run of failures inside a window, which is comfortably longer than nearly every provider interruption and comfortably shorter than the time it takes anyone to notice a stopped campaign by hand.

Setting it lower would bring back the original problem in a smaller form. Setting it higher would let a genuine failure sit unreported for most of a working day, which for a mailbox that carries several campaigns is expensive.

The number is per connector rather than global, because providers differ. A mailbox on a provider that is reliably slow gets a little more room than one on a provider that either works or does not.

What you will notice

Mostly nothing, which is the point. Transient failures happen, get retried, and resolve without anything appearing on a screen.

What you should notice is that a failing status now means something. If a connector says failing, it has failed consistently, and reconnecting it will involve actually changing something rather than clicking through the same settings that were already correct.

Sending during a wobble

A message due to send during a brief interruption is not dropped. It waits and goes out when the connection recovers, usually within the same sending window.

If the interruption outlasts the window, the message moves to the next one rather than sending at an hour you did not choose. Sending at three in the morning because a provider had a bad evening would be worse than sending a day late.

Availability

Live now for all connectors on all plans. No configuration required.