ناوەندی یارمەتی کۆکارWhy didn't my automation run?
Reading the run history, what each outcome means, and the handful of reasons a rule stays quiet.
Open the ⚡ menu on a space, folder or project, find the rule and choose History. Every rule keeps its own record for 30 days.
What each outcome means
| Outcome | What happened | What to do |
|---|---|---|
| Ran | It matched and changed something | Nothing |
| Nothing to do | It matched and was allowed, but the task was already how the rule wants it — or the action had nobody to act on | Usually fine. If you expected a change, check the actions are pointing where you think |
| Blocked | The person who created the rule can no longer do this — they lost access to the task, or lack a permission one of the actions needs | Have someone with the right access recreate it, or change the action |
| Held back | The rule already ran on this task in the same chain of automations | Nothing — this is the loop guard doing its job |
| Paused — monthly limit | The workspace has used all its actions for the month | Wait for the 1st, or upgrade. See Limits and usage |
| Paused — plan expired | The workspace is read-only until the plan is renewed | Renew the plan |
| Failed | An action hit an error and everything that rule tried was undone | Read the reason on the row — it is usually a status, project or field the rule names that no longer exists |
Nothing in the history at all
A rule whose trigger or conditions did not match writes nothing. That is deliberate — a rule that matches one status change in a hundred would otherwise bury its real runs under ninety-nine rows of "did not match".
So an empty history is itself the answer: the event did not happen the way the rule describes it. Check, in this order:
Is the rule switched on? A rule Kokar switched off itself shows a reason next to it — the usual one is that the person who created it has left the workspace.
Does it cover this kind of task? Rules apply to top-level tasks by default. If the thing that changed was a subtask, set Applies to accordingly.
Is it attached to the right place? A rule on one project does not see another project's tasks. The ⚡ drawer shows both the rules that belong to a location and the ones it inherits from above.
Is the trigger narrower than you remember? "Status changes" with a to Done setting does not fire when a task moves from Done back to In Progress.
Are the conditions all true? Conditions set to all need every one to match. Switch to any if you meant one of them.
It fires more often than I want
- Add a condition to narrow it, or narrow the trigger itself — "status changes to Done" instead of "status changes".
- Check Applies to. A rule set to Both also fires on every subtask.
- Remember that inherited rules stack: a space rule and a project rule can both match the same task, and both will run.
Something happened that I can't explain
Open the ⚡ drawer on the task's project. Everything that can touch a task in that project is in one of the two lists, including the rules inherited from the folder or space above, each labelled with where it comes from.
For a workspace-wide view — every rule and everything they have done recently — go to Settings → Automations. You will only ever see rules and activity for places you already have access to.
An automation posted a comment as me
Comments and notifications an automation creates are attributed to the person who
created the rule, because that is whose permissions it runs with. The comment
text can say so explicitly if you want — put {{automation.name}} in it.
Frequently asked questions
Where is the run history?
Open the ⚡ menu on the location, find the rule, and choose History. Settings → Automations has the same thing for every rule in the workspace, plus a workspace-wide activity list.
My rule says "Nothing to do". What does that mean?
It matched and it was allowed to run, but the task was already in the state it wants — or the action had nobody to act on, like notifying assignees on an unassigned task.
There is no entry at all for something I expected. Why?
A rule whose trigger or conditions simply did not match writes nothing, on purpose. An empty history usually means the trigger never actually happened the way the rule describes it.
Why does the history stop after a while?
Run history is kept for 30 days.
My automation ran once and then stopped in the middle of a chain. Why?
A rule only runs once per task in a single chain of automations. It stops rules that point at each other from bouncing back and forth forever, and the history records it as "Held back".