MyBotBoxMyBotBox

Trigger Health & Reliability

How MyBotBox keeps triggers reliable — retries, deduplication, backfill, and recovery.

Triggers are the entry point to every deployed workflow, so they're built to be reliable even when an upstream service is flaky. You don't have to configure any of this — it's on by default.

Webhook deduplication

Inbound webhooks can be delivered more than once. MyBotBox records a fingerprint of each event and ignores duplicates, so a workflow fires exactly once per real event even if the provider retries delivery.

Providers that sign their webhooks (Slack, Stripe, GitHub, and others) are verified before they're accepted — an unsigned or mis-signed payload is rejected.

First-poll backfill

When a polling trigger (RSS, IMAP, Gmail, Outlook, Google Tasks) runs for the first time, it baselines the source instead of flooding your workflow with the entire history. You choose what the first poll does:

ModeFirst poll behavior
SkipMark everything as seen; fire on new items only
Last NFire on the most recent N items, then continue from there

After the first poll, only genuinely new items trigger a run.

Retries and backoff

A poll or dispatch that fails is retried with backoff rather than dropped. Transient errors (a provider timeout, a brief outage) recover on their own without losing events.

Automatic recovery

A background monitor checks trigger health on a schedule. A trigger that has been failing is re-armed automatically once the underlying issue clears, so workflows resume without manual intervention.

If a trigger keeps failing — for example, an expired credential — re-authenticate the connection it depends on. The monitor recovers from transient faults, but it can't fix a revoked token.