Trello automation logs: trace a missing outcome before retrying

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Describe the missing outcome precisely

Trello's automation logs show runs, actions, errors, warnings and changes to triggers or actions. The individual automation log focuses on one automation. The activity log shows automation activity carried out on your behalf across boards you can access.

Use those scopes deliberately. Our recommendation is to identify a specific card, expected event and missing change before opening logs. A statement such as automation is broken is too broad to distinguish a missing trigger from a failed action or an incorrect expectation.

A fictional missing deadline

Assume moving a request to Ready should add a label and a deadline. The label appears but the deadline does not. Repeating the move immediately could obscure the original evidence and create another attempt. First record the card reference, the approximate event time and the actual result.

This scenario is a diagnostic exercise. It does not report a real failure or prove a particular cause in Trello.

Collect a minimal incident record

• Card and board reference, using non-sensitive identifiers in shared notes.
• Expected trigger and its qualifying conditions.
• Expected actions in order.
• Observed result for each action.
• Relevant log entry, timestamp, warning and error details.
• Recent trigger or action changes.

Follow the evidence

1. Open the relevant board's Automation controls.
2. Find the individual automation and inspect its log.
3. Match the event to the expected card and time.
4. If no matching run appears, review whether the trigger actually occurred and satisfied its conditions.
5. If a run appears, inspect each action and any reported warning or error.
6. Use the wider activity log when another automation may explain an unexpected change.
7. Compare log evidence with the current card before deciding what to repeat.

Retry only the intended work

Our operational advice is to distinguish repair from replay. If one expected change is missing while another completed, define whether a full repeat is appropriate or whether an authorized targeted correction is clearer. Do not assume that every action is harmless when repeated.

Rehearse the revised automation using a synthetic card with a known initial state. Record expected and observed outcomes separately. If multiple rules react to the same transition, review the sequence as a whole rather than diagnosing only the most visible rule.

Acceptance criteria

Close the incident when the evidence explains the result, the intended final state is restored through an authorized process and a controlled follow-up produces the expected outcome. Keep a brief note of the cause and relevant configuration revision. Avoid claiming a cause solely from the absence of one entry in a log whose scope you have not checked. This source-based troubleshooting procedure does not inspect your account, perform a retry or guarantee that historical log evidence will cover every incident.