Auto-disable & recovery

When an integration keeps failing, letting every report run through three attempts is wasted work. Auto-disable exists so failure becomes visible instead of silently retried forever.

When it triggers

• 20 consecutive failed deliveries on the same integration (each delivery already includes 3 attempts)
• The integration is set to disabled and its owner receives an email notification

How “consecutive” works

• Any successful delivery resets the counter to zero immediately
• Test writes do not count as failures (so debugging never trips it), but a successful test does reset the counter
• The counter is stored on the integration and survives service restarts

Daily safety-net scan

Besides the real-time check on the delivery path, a daily maintenance job also scans for integrations that are “still active but have ≥ 20 consecutive failures” and disables them — covering edge cases where background retries did not finish.

While it is disabled

• New reports are not delivered to that integration (they still land in the feedback list — nothing is lost)
• Nothing is backfilled: once re-enabled, only new reports are delivered. If reports from the disabled window are needed in the table, share them again from the feedback list
• A disabled integration no longer appears in the destination picker

Recovery

1. Check the delivery log and fix the root cause (expired credentials, table permissions, unreachable endpoint…)
2. Verify with the “Test” button
3. Re-enable the integration in its settings — status returns to active and the counter starts from zero

The most common root cause: expired credentials

With Method B (custom app), an expired tenant_access_token is refreshed and retried automatically; but a reset app secret or a disabled app cannot self-heal, and that is the most common cause of auto-disable. The notification email includes the last error.

See also

• Delivery logs & retries — how to read the failure