How to read a run history like a mechanic

<h2>The history is the product</h2><p>An automation you cannot watch is a rumour. The flow builder gets the attention because it is where the work happens, but the screen people actually open at nine in the morning is the run history, and it is the only reason anybody trusts a process that runs without them.</p><p>Most people read it wrong, in a specific and fixable way: they scan for red, see none, and close the tab. Here is how to read it properly, in about the same amount of time.</p><h2>A history is four columns</h2><pre><code>run 8812 09:03:12 ok read 14, wrote 14 run 8813 09:06:12 ok read 0, nothing to do run 8814 09:09:12 partial read 9, wrote 8, skipped 1 run 8815 09:12:12 failed destination returned 429, retry queued run 8816 09:22:41 ok read 9, wrote 9 </code></pre><p>Five lines, and four different stories. Run 8813 read nothing, which is either healthy or the most important line on the page depending on the time of day. Run 8814 wrote most of a batch and dropped one record. Run 8815 hit a rate limit and recovered by itself ten minutes later, which is the system working as designed and not an incident.</p><h2>Five statuses and what each one means</h2><table><thead><tr><th>Status</th><th>Meaning</th><th>Do you act</th></tr></thead><tbody><tr><td>ok</td><td>Every record read was written</td><td>No, unless the count surprises you</td></tr><tr><td>ok, zero records</td><td>Nothing matched the trigger</td><td>Only if you expected records</td></tr><tr><td>partial</td><td>Some records written, some skipped with reasons</td><td>Yes, read the skipped list</td></tr><tr><td>failed</td><td>The run stopped, a retry is scheduled</td><td>Not immediately, check the next attempt</td></tr><tr><td>parked</td><td>Retries exhausted, payload kept for 14 days</td><td>Yes, this one needs a person</td></tr></tbody></table><p>Note which row demands the least urgency. A single failed run with a retry queued is usually the network being the network. A run that fails, retries and fails again is a different animal, and the history shows the attempt number so you can tell them apart at a glance.</p><h2>Reading a partial run</h2><p>Partial is the most informative status and the easiest to skim past, because the counts look mostly fine. Nine read, eight written is a ninety percent success rate that will quietly delete one record a day from your reporting.</p><p>Expand it and you get the record identifier and a reason for each skip. In practice the reason is nearly always one of four things: a select option that no longer exists, a required field with no value, a person who could not be matched, or a destination that rejected the record's own content, usually a file too large or a text field over its limit.</p><p>All four are one-line fixes in the mapping. None are visible unless you open the run.</p><h2>Three questions for a failed run</h2><ol><li><strong>Is this the first attempt or the fourth?</strong> First attempt failures on a transient code such as 429, 502 or a timeout usually need nothing from you. A fourth attempt means the condition is persistent.</li><li><strong>Did the source change or did the destination change?</strong> The error names the side that refused. An authentication error is nearly always the source, a validation error is nearly always the destination, and knowing which halves your search.</li><li><strong>Did this ever work?</strong> Scroll to the previous successful run and read the timestamp. A flow that worked at 09:03 and failed at 09:12 points at something that changed in those nine minutes, which is a far smaller haystack than the whole configuration.</li></ol><blockquote><p>I ask my team for the run number, not a description. Every question I would ask is already on that screen, and the number gets me there in one click.</p><p>Anouk Delacroix, operations director at Wren and Halloway</p></blockquote><h2>When the history is green and the data is wrong</h2><p>This is the case worth learning, because the history is telling the truth and the truth is incomplete. Every run reads zero records and reports ok, so the flow looks perfectly healthy while nothing has moved for a week.</p><p>Three causes cover almost all of it.</p><ul><li><strong>The trigger no longer matches.</strong> A view filter was tightened, a label renamed, a folder reorganised. The flow is watching a door nobody walks through any more.</li><li><strong>An upstream flow stopped.</strong> Your flow is fine and its input dried up two steps earlier, which is why it is worth checking the run history of the flow before yours.</li><li><strong>The deduplication step is matching too aggressively.</strong> Records are being treated as updates to something that already exists. The counts look plausible and nothing new ever appears.</li></ul><p>The habit that catches all three costs about fifteen seconds a day: glance at the record count, not the status colour. A flow that normally moves twelve rows and moved zero this morning is worth a look even with a green tick beside it, and a flow that normally moves twelve and moved four hundred is worth a look before somebody else finds it.</p>