Reliability and monitoring

A bridge is infrastructure: nobody watches it, and its failure mode is silence, which is indistinguishable from a quiet week. So ThreadBridge checks its own bridges, restarts what it can, and emails you when it can't.

Health checks

Every two minutes, each bridge that should be up is asked whether it actually is. A healthy answer records the check on the bridge page. An unhealthy one starts the recovery path below.

Automatic restarts

A bridge that should be running but isn't gets restarted automatically, up to three times. Each attempt is written to the bridge's event list, so a bridge that keeps flapping shows its history rather than looking healthy between failures.

After three attempts the bridge is left in Error and no longer restarted. That cap is deliberate: a bridge whose token was revoked or whose channel was deleted will fail identically forever, and restarting it every two minutes would only bury the reason.

Alerts

If a bridge stays down for five minutes, the account owner gets one email naming the bridge and the error. Just one, not one every two minutes, so the alert stays meaningful. Fixing the cause and restarting the bridge re-arms it.

Surviving restarts of ThreadBridge itself

Bridge state lives in the runtime's memory, so a deploy or a host restart would otherwise leave every bridge stopped while the dashboard still claimed they were running. On start, the runtime asks for the list of bridges that should be up and brings them back. If the control plane isn't reachable yet (the normal case when both are deploying at once), it retries with backoff instead of giving up, and one bad configuration doesn't stop the others from returning.

Duplicate-delivery protection survives the same restart. The mapping between the two platforms' message IDs for each relayed message is persisted rather than kept only in memory, so a message relayed moments before a deploy is still recognized as already-handled afterward instead of being relayed a second time.

Token refresh

Microsoft access tokens are refreshed in the background every fifteen minutes for credentials approaching expiry, and the running bridge is given the new token. Slack bot tokens don't expire; they stay valid until the app is removed from the workspace or the token is revoked.

What isn't guaranteed

• Messages posted while a bridge is down are not relayed once it comes back. There's no queue and no backfill; the bridge resumes from the moment it's running again.
• Ordering is best-effort. Two messages posted a fraction of a second apart normally arrive in order, but nothing forces it across two independent platforms.