An uptime check asserts that the scheduler fired and the process exited clean. It measures your executor; it says nothing about where the work is actually flowing, which is why the author of the dev.to post can say his failed automations were still running on the day they were declared dead [1].
Read the distributor case as a denominator problem. The dashboard's numerator is orders that arrived through the link or the WhatsApp flow [5]. The denominator is real orders, and after three months most of those were still landing on the sales coordinator's phone, entered later, sometimes days later, sometimes never [6][7]. Nothing inside the system can measure the denominator, because the workaround is the thing hiding it. Dispatch worked this out faster than the owner did and kept calling her to confirm, which is what turned a generated list into decoration [8]. A list nobody trusts is cheaper to produce than one they do, which quietly erodes the efficiency the project was funded to deliver.
So you instrument proxies. Of the five abandonment signals the post lists, three are computable from data the workflow already writes [19]. Batching: take the gap between the event timestamp and the entry timestamp, per submitter, and look for clumps arriving in the evening or just before a review meeting, which the author reads as backfilling rather than working [15]. The downtime excuse: join each "the system was down" complaint against the health log, because when the log says up you have found an agreed social permission rather than a fault [16]. Concentration: count the distinct people who clear stuck entries, since one operator who is the only route to a fix is the pre-project single point of dependency in new clothes [17].
The other two signals need a human. A parallel Excel file, private group, or paper register does not appear in your telemetry, and the author's test for it is to ask casually where someone would check a detail from last Tuesday, then watch where they look [14]. Exception volume growing instead of being folded into the workflow is the other [18]. The author's threshold is that any two of the five together mean the automation is on life support [13].
The political half of this carries real weight of its own. The tasks worth automating are the ones a capable person currently controls, and the post argues their workarounds are rational: they absorb a dual-run period where feeding the new system is extra work on top of the real work with no load taken off them, and they eat the customer's anger when an automated reply quotes an outdated price [9][10][11][12]. My own posture, in my context: scope release one so it removes a step from the person who owned the task, not so it adds one, and accept capturing less of the process to get that.
What would have to be true for this to transfer. The failure needs a human input step and a side channel that the counterparty already prefers, which in this account is distributors phoning a coordinator [4]. Machine-to-machine ingestion has no equivalent bypass; it fails loudly, in a queue. Also worth pricing honestly: this is one practitioner's account of a pattern in distributor-led businesses, framed as political rather than technical, and "a fraction of the real order volume" is a description, not a measurement [3][6].
