The debugging order that saves an hour
- Is the rule enabled, and was it enabled at the time in question?
- Was the triggering event actually emitted for that record?
- Did the conditions match, including the previous-state condition?
- Was a run created, and what status did it settle in?
- Was the action attempted, and what did the provider return?
- Was the result written back to the record?
- Did the outcome actually occur in the real world?
What an execution record has to contain
At minimum: which automation, which trigger event, which record, when, how long it took, the overall status, and the result of each individual action. Without per-action detail, a run that sent the email but failed to create the task shows up as a single ambiguous entry.
It also needs to be readable by an operator, not just an engineer. The person who configured the rule should be able to answer 'did it run and what happened' without asking anyone.
Execution history versus audit trail
They are different records with different jobs. Execution history answers 'did the automation do its work', and it is noisy by design — every run, including the boring successful ones. The audit trail answers 'who changed this record and when', and it should be selective, permanent and attributable.
Keep both. Deleting execution history to reduce noise is fine; deleting audit records to reduce noise is not.
Monitoring that people actually read
- Watch the failure rate per rule, not the individual failures.
- Watch queue depth — a growing backlog is the earliest warning of trouble.
- Watch for rules that have not fired at all in a period they should have.
- Review the noisiest rule every month and either fix it or turn it off.
- Give every automation an owner who receives its failures.