Direct answer
Before editing the automation or integration, find out what changed and what actually stopped. First check whether it is still switched on and whether anything ran at all. Then work through causes in order: the trigger, the credentials, the other system, the hosting. Record what you see before you change anything, so you can undo a wrong guess. Finally, work out which data was missed and replay it without creating duplicates. Nothing here guarantees a fault will be found; some causes sit in systems you do not control and need someone with access to them. For how to be told early next time, see automation monitoring and alerting.
Triage: stopped entirely, or partly wrong?
The pattern narrows the search. If it stopped suddenly, look for one event: a password change, a person leaving, a plan change, a software update. If it degraded slowly, for example some records arrive and others do not, look for a rule or a field: a filter, a required value, a renamed field, a limit being reached. Write down the last time you know it worked and the first time you know it did not. The gap between them is where the change happened.
First: is it switched on, and did anything run?
Check the obvious first. Is the workflow enabled? Was it paused or deactivated after an edit? Does the run history show any run, and does the last run show an error? A workflow that never started points at the trigger; one that started and stopped partway points at a step, and its error text is your best lead. Copy the error text exactly.
Trigger side
When nothing starts, look at how it is started. If it waits for an incoming message, check that the address the sending system uses is still the one the automation listens on; edits, restarts and moving between test and production can change it. If it starts on a schedule, check the schedule is still active. If a step was disconnected during an edit, the flow may end before it reaches the rest.
Credentials
Expired or revoked authorisations are a leading cause of sudden stops. Check whether the connection was made with a personal login, and whether that person changed a password, left or lost access. A connection tied to a person is fragile; the API credentials and service account setup page covers how to avoid it. Re-authorising may fix it, but confirm you have the right to do so and use an account owned by the business.
The other system
The connected system may have changed without warning to you:
- A plan or licence change that removed access or lowered a limit
- A rate or usage limit that is now being reached
- A field renamed, removed or made required, so records are rejected
- A change made by the vendor to how the connection works
- A user removed, or a permission taken away
Hosting
If the automation runs on a server or a hosted service, that service can stop or run short of resources. Check whether it is running, whether the account is in good standing, and whether it was updated recently. If you do not know who hosts it, that is a finding in itself: record it.
Recovery: what is missing, and how to replay it
Once it runs again, list what was missed between the last good run and the fix. Replay those items only once, and check that the receiving system does not create a duplicate for a record it already has. Then run a catch-up comparison: counts and identifiers in both systems for the gap period. A small test with one record comes before replaying many. If some items cannot be replayed safely, list them for manual entry.
What to record and who to tell
Write down what you saw, what you changed, when, and what you replayed. Tell the people who rely on the output that data for the gap period may be late or incomplete, and say when you expect it to be complete without inventing a time. Keep the notes; the same cause tends to return.
When outside help may be needed
Bring in a specialist when the cause sits in a system you cannot access, when the setup is undocumented and nobody knows how it was built, or when replaying risks damaging live data. Prepare: the last known good time, the error text, what changed recently, who owns each connected system, and the list of missed items. Well-prepared notes shorten any diagnosis. This page is not a repair or maintenance offer; if you need something rebuilt or documented properly, that is scoped as a project.
Questions
What is the most common reason an automation stops?+
There is no single answer, but expired or revoked credentials, a changed trigger address, a limit being reached and a renamed or newly required field are frequent suspects. Check them in order.
Should I just switch it off and on again?+
Look at the run history and error text first. Restarting can hide the clue and does not replay what was missed.
How do I avoid duplicates when replaying missed data?+
Replay one record as a test, confirm how the receiving system treats a record it already has, and compare counts afterwards.
Who should own the fix?+
The person who owns the automation, with help from whoever administers the connected system. If nobody owns it, that gap is the first thing to fix.
Can LATYNEX take over an automation nobody documented?+
Not as a standing service. Where the setup is unclear, the honest first step is to document how it works, and rebuilding may be scoped separately.