Counting silent automation failures requires a run_id that survives the platform unchanged

Three records and a reconciliation, all written by code you own. A controller writes the event before it sends anything: `run_id`, the workload, which platform copy this event went to, a sequence number, and `fired_at` ^[7]. Every action inside the workflow posts a receipt back to a destination you control, echoing the event and naming the step that produced it ^[10]. The destination stamps `received_at` on arrival ^[11]. The controller also records, per event, whether the platform accepted the send, and if not, why not ^[12].

That third record is the one an in-house harness usually skips. Without it, an event with no receipt is ambiguous between the platform refusing it loudly, in which case a retry was available, and the platform accepting it and losing it ^[13]. The author describes a soak run where four sends failed, the harness recorded `send_ok = 0` and threw the error away, and connection reset, timeout and non-2xx are now permanently indistinguishable for those four events ^[14]. "The fix took ten minutes. The data is unrecoverable," the author wrote ^[15].

Reconciliation is per event: for each fired event, count the receipts carrying its `run_id` and compare that against what the workload expected ^[16]. This works only if `run_id` is unique per event and reaches the destination unchanged ^[8]. A platform that rewrites or drops fields it does not recognise on the way through is not measurable this way ^[22].

The rate uses two of seven counts, and the spec asks you to publish all seven, because the remaining five are how a reader checks that the two mean what you say they mean ^[19]. A `filtered` count that comes in suspiciously high, or a nonzero `filter leak`, says the workload is not doing what you think and the rate is measuring something else ^[19].

Latency here is `received_at - fired_at`. It includes platform processing and both network legs, which makes it an upper bound on the platform's own execution time ^[11][23]. The author says comparing the two figures is meaningless ^[11].

A rate produced this way describes one workload on one platform copy, since the event record names both ^[24]. For someone else's published figure to tell you anything about your automation, the trigger behaviour and the destination's response semantics would have to resemble the ones measured, because those are what decide whether a run gets created at all and whether success can be evaluated ^[26]. The author says the spec sets out the metric, its exclusions, the data contract that makes it computable, and the conditions a published number has to meet ^[5], and that the repeated question about the measurements was not about the results but "how are you counting that" ^[25]. The post is the engineering half ^[20].