When an integration stops working
Six causes account for nearly every broken integration. Work through them in this order.
Integrations fail silently far more often than they fail loudly, which means the first thing to establish is when it stopped rather than why. Something changed on one side or the other, and the list below is ordered by how often each cause is the answer.
Steps
Check whether the key was revoked
Especially if somebody recently left. Revoking a departing person's access breaks every integration built with their key, and nothing connects those two events for you.
Check the workflow is still Live
A catch hook fires into a workflow. If somebody toggled it off during an incident and never back on, nothing happens and nothing errors.
Check the workflow owner's notifications
Failures are reported to the owner. If that person has been deactivated, the failures have been going nowhere — possibly for weeks.
Check the schema did not change
A deleted or retyped attribute breaks anything writing to it. So does renaming a dropdown choice, which is a much smaller-feeling change than it is.
Check the outside system
Zapier, Make and Integrately all disable automations after repeated failures, quietly. Log in and look rather than assuming it is still enabled.
Test the two halves separately
Post to the catch hook by hand and see whether Convarza's half works. That single test immediately tells you which side to fix, and saves you from debugging the wrong one.
Check it worked
Once it is fixed, add something that would have told you sooner — a workflow that alerts when nothing has arrived for a day, or a weekly check by a named person. Whatever you build, give somebody a reason to notice it stopped.
The parts people get wrong
- Integrations fail silently far more often than loudly. The monitoring is not optional.
- One key per integration means you can revoke one thing without breaking everything else.