LearnGrokA routine that quietly stops is worse than one that fails loudly, because you find out from the absence of a result. Work down this list; the causes are ordered roughly by how often they turn out to be the answer.
Check: in order
- Is the routine still enabled? The obvious one, and it is first for a reason.
- Is the schedule right, including the time zone? A routine that runs at the correct hour in the wrong zone looks exactly like one that did not run.
- Does the owning Bot still exist? Deleting a Bot removes its routines.
- Are the required plugins still authenticated? An expired authorisation breaks the run rather than the schedule; see A Bot's plugin will not install or authenticate.
- Can the computer reach the source system? A machine that was recovered or recreated may have lost the session the routine depended on.
- Has usage or account access been paused? An exhausted allowance or a reached spending limit stops work, and this is easy to miss because it is not a fault in the routine at all.
- Then read the recent run history, which is where an actual failure will be recorded.
The one that catches people
Routines can be paused automatically after a long period away. If you were on leave, came back, and the automation had simply stopped, that is likely what happened, the pause comes with a prompt, and an unanswered prompt leaves it paused.
It is worth checking your routines after any gap, rather than assuming silence means success.
Event-triggered routines
If the routine fires on an event rather than a clock, the checks are different: confirm the source channel or repository is still the right one, and that the matching rule still matches. Renamed channels and moved repositories are the usual culprits.
Testing without causing damage
There is a test-run control, and it is genuinely useful, but a test run performs real actions in real systems. It is not a dry run. Test with input you would be comfortable seeing acted upon, and never test a send-or-publish routine against live recipients.
Preventing the next one
- Pause a routine when its source system changes. A tool migration is a good moment to pause and re-verify rather than discover the failure a week later.
- Have the routine report what it did, including what it skipped and why. A routine that only speaks up on success gives you nothing to notice.
- Review active routines periodically, alongside connected tools. Both drift.
What changes
Routine controls, event triggers and the auto-pause behaviour are all developing. Confirm current behaviour in the automation documentation.
