Diagnosing Trello Butler Rules That Fail to Fire

The problem: a Butler rule runs silently

You configure a Trello Butler rule to add a label, move a card, post a comment, or change a due date when a card event happens. The card's activity feed shows the event—someone moved the card, added it to a list, or changed a field—but the expected label, move, comment, or date change never appears. The same rule may work on another board or for another colleague.

Useful takeaway: most silent Butler failures fall into five categories—rule disabled or archived, trigger mismatch, permission or workspace restriction, plan quota or Power-Up conflict, and data mismatch such as label names, custom fields, time zones, or checklist state. Isolate the cause on a scratch board before changing production automation.

Recognizable condition

A Butler rule is failing when all of the following are true:

• The rule exists in the board's Butler directory and appears enabled.
• A card experiences the event the rule is supposed to watch.
• The event appears in the card's activity history.
• No corresponding Butler action appears in the card history or Butler log.
• The expected board-level change (label, list move, comment, checklist item, due date) does not occur.

Likely causes and quick diagnostics

Condition	Quick diagnostic
Rule disabled or archived	Open Butler on the board; the rule toggle is off or the rule appears in the archived rules list.
Trigger mismatch	The rule watches "card added to list" but the event was "card created on board," or the rule watches a specific list while the card moved to a different one.
Permission or workspace restriction	Your account lacks edit permission on the board, or the board is in a workspace with automation restrictions for your member role.
Plan quota or Power-Up conflict	Rules stop after reaching monthly command usage, or behavior changes after enabling another Power-Up.
Data mismatch	Label names, custom field values, member names, due dates, or time zones differ from what the rule expects.

Ordered checks

1. Confirm the board is active and editable. Open the board. If it shows as closed or archived, automation will not run. Confirm you can edit a card title or move a card; if you cannot, your member role lacks write access.
2. Open Butler and verify the rule state. Click Automation in the board header, open the relevant rule type (Rules, Card buttons, Board buttons, Due date commands, or Calendar commands), and confirm the toggle is on and the rule is not archived.
3. Compare the trigger to the actual event. Read the rule trigger exactly. "Card added to list" is different from "card created in board." "Card moved to list" requires the destination list to match the rule's list selection.
4. Create a minimal test on a scratch board. Make a new board with one list and one label. Add one rule: when a card is added to the list, add the label. Add a card and watch whether the label appears. Do not use production cards for this test.
5. Disable other rules and Power-Ups temporarily. Turn off every other Butler rule on the board and disable unrelated Power-Ups, then repeat the test. Re-enable them one at a time if the test passes, watching for the failure to return.
6. Inspect the data the action depends on. If the rule adds a label, confirm the label name matches exactly, including capitalization. If it sets a due date, confirm the source date field exists and uses an explicit date, not free text. If it mentions a member, confirm that member is on the board.

Fixes tied to findings

• Rule disabled or archived: Toggle the rule on, or restore it from the archived rules list. Rollback: toggle it off again if the re-enabled rule produces unwanted actions.
• Trigger mismatch: Edit the rule to use the exact trigger that matches the event. If you need manual execution instead of event-driven automation, convert the logic to a card button or board button.
• Permission or workspace restriction: Ask a board admin to add you as a member with edit rights, or move the board to a workspace where your role permits automation. Do not change workspace security settings on a production workspace without admin approval.
• Plan quota or Power-Up conflict: Reduce command volume by combining rules or raising thresholds, split rules across boards, or confirm your current plan limits before upgrading. If a recently added Power-Up coincides with the failure, disable it and retest.
• Data mismatch: Normalize label names, custom field names, and member references in the rule. Use explicit date fields rather than text descriptions. Check the card's actual data in the activity feed instead of assuming the field exists.

Escalation criteria

Escalate to Trello or Atlassian support when:

• A minimal reproduction on a scratch board still fails after you confirm the rule is enabled and the trigger matches the event.
• The rule is enabled, trigger-matched, and the action still never executes.
• Behavior differs between users who have identical board permissions.

When you contact support, be ready to provide: the board URL, the rule name and its trigger/action text, timestamps of failed events, a link to the test card, and screenshots of the Butler rule configuration and the card's activity history.

Verification on a scratch board

1. Create a scratch board with one list and one label.
2. Add a single Butler rule triggered by "card added to list" that adds that label.
3. Add a card to the list.
4. Open the card's activity history and the Butler rule entry. If the trigger event is present but no action is logged, the problem is trigger matching or execution, not card creation.
5. Repeat the test as a different workspace member with edit access to separate permission failures from rule defects.
6. Run the test in a private or incognito window with browser extensions disabled to rule out cached Power-Up state or browser-side blockers.

Limitations

Butler triggers, actions, quotas, Power-Up availability, and workspace security settings vary by Trello plan and can change without notice. This guide assumes the current Trello web application. Revalidate any limit or menu path against Atlassian's current documentation before treating it as fixed. Butler UI automation is separate from Trello's REST API and webhooks; a failing webhook does not prove a Butler rule is broken.

Do not run destructive tests such as archiving, deleting, moving, emailing, or changing members on production boards. Use a scratch board and disposable cards.