Hi Team,
Many of the job triggers from orchestrator got disabled.
We have checked the audit log to see who and why got diabled and found the below:
User System Administrator applied archive retention policy (action: jobs removed) for process Unattended_BOT_07
Please investigate and do let us know the reason.
Regards,
Raja Surath
I don’t think that audit entry is the cause of your disabled triggers. It’s an unrelated, scheduled event that happened to be in the log around the same time.
What archive retention policy (jobs removed) actually means?
This is the Process Data Retention Policy doing its normal, scheduled job:
It runs automatically (once per calendar day) against jobs that are in a final state (Successful, Faulted, Stopped) and older than the configured retention window.
Action “Archive” = it copies those finished job records to your storage bucket, then removes them from the Orchestrator database to keep it lean.
This applies only to jobs that have ended more than X days ago, where X is the retention duration you configured for that process.
Look around the audit logs for some other reasons as this action no way touching the triggers.
++ Refer this thread as well for possible reasons.
the log does not related as @ashokkarale has pointed out
one possible reason if not disabled by someone would be that if more than x number of times if the trigger is not able to trigger the job due to wrong password or any other reason the trigger gets auto disabled..check on the same
cheers
Hi @raja_surath
I think your triggers were turned off by Orchestrator’s automatic health policy. By default, Orchestrator will automatically disable a schedule/trigger if it records 10 consecutive execution failures within a rolling 24-hour period without a single successful run. This stops broken or misconfigured automations from infinite error loops that overload your robot infrastructure.
Cheers
Hi Raja
agreeing with the others that the retention policy entry is a red herring, that one only archives old finished jobs, it doesnt touch triggers
the detail that catches my eye is that many triggers got disabled around the same time. When that happens its usually not each process failing on its own, its somthing they all share. A machine template that went offline, a robot account with expired credentails, a license that ran out, that kind of thing. Every trigger pointing to that same robot fails to launch jobs over and over, each one hits the auto disable threshold and orchestrator turns them off one after another.. So maybe worth checking what those triggers have in common before anything else
to confirm the real reason you could check the Alerts page, when orchestrator disables a trigger automatically it raises an alert saying why. And in the audit log dont stop at the retention entry, filter for the update action on the triggers themselves around the time they went off, the disable shows up there with the reason. The jobs page also helps, look at the history of those processes right before and you will probably find a bunch of pending or faulted jobs that never started
once you fix whatever is common there, reconnect the machine, update the password, free up licenses, just re enable the triggers and they should hold. hope it helps