Maintaining integrations and automations: detect, retry and document failures
An automation that works today can fail silently tomorrow: an access token expires, an API changes a field, a usage limit is reached. The real danger is less the failure itself than nobody noticing it. The rules below make failures visible, recoverable and documented.
Know the usual causes of silent failures
Most problems originate outside your own workflow. For each integration, decide how these cases are detected and who responds.
- Expired or revoked credentials, for example after a password change or an employee leaving.
- Changed fields or new required values in the CRM or store.
- Usage limits reached on an API or automation service.
- Temporary outages of a connected service.
- Unexpected input such as empty fields, special characters or duplicate submissions.
Log every run so it can be traced
Store a unique identifier, timestamp, source, result and, on failure, the target system's error message for every run. This lets you find a single enquiry without pasting customer data into chat messages. Keep logs only as long as agreed for operations and data protection.
The original record must survive even if forwarding fails. A website enquiry is stored first and then sent to the CRM. If that transfer fails, the enquiry is not lost; it waits to be processed again.
Retry safely without creating duplicates
Temporary errors are often resolved by automatic retries with increasing delays. Cap the number of attempts and move permanently failed runs to a queue for manual review.
So that a retry does not create a second contact or invoice, the workflow checks the identifier before creating a record and skips it if it already exists. Test exactly this case before launch.
- Alerts go to a named person, not a shared channel nobody owns.
- Alert on persistent failure, not on every single retry.
- Flag missing activity, for example no enquiries for several days.
- Link to the log entry instead of copying customer data.
Example incident and runbook
Example: the CRM access token expires. Website enquiries are still stored, the transfer fails after three attempts and the owner receives an alert linking to the queue. After reconnecting, queued runs are processed; the identifier check prevents duplicates. The log records cause, duration, affected runs and the action taken.
Keep a short runbook for each integration: purpose, systems involved, account owner, responsible people, alert route, retry rules and recovery steps. Review it after every change and on a fixed schedule.
Frequently asked questions
- Do I need a dedicated monitoring tool?
- Not always. Many automation services provide execution logs and failure alerts. What matters is a clear owner and one place where failures from every system are visible.
- How often should integrations be checked?
- After any change to a connected system and on a fixed schedule. Review logs, the failure queue, expiring credentials and whether expected runs are arriving.
Describe your current automations and where failures last showed up. We can discuss logging, retries and ownership.
Discuss your automations