What is being monitored, and in what order
Three things, and they answer different questions. Liveness: is this workflow running at all. Correctness: is it doing the right thing when it runs. Health of the estate: is the total picture drifting.
Liveness is where almost all the value is and it is the cheapest to build, so it goes first. Correctness is expensive and belongs only on the paths where being quietly wrong is costly. Estate health is a quarterly review rather than an alert.
The prioritization rule is a single question asked of each workflow: what would a four-month silent outage cost. Rank by that answer, instrument the top handful properly, and consciously accept the risk on the rest. Five monitored workflows and forty unmonitored ones is a defensible position; forty-five noisy alerts is not, because the second state gets muted and produces blindness with the appearance of coverage.
It is worth separating this from making automations more robust, which is a different project. Robustness reduces how often things break; monitoring reduces how long a break goes unnoticed. A business with fragile workflows and good monitoring is in a substantially better position than one with robust workflows and none, because the second one is exposed to a failure it will discover through a client.
The architecture, part one: expectation checks
Stage one is declaring the expectation, and it belongs in the register alongside what the workflow does. For each monitored workflow: the expected run frequency as a range, and the tolerance window before absence is meaningful. A workflow that fires on new client signups might expect two to eight runs a week; one that runs nightly expects seven.
Stage two is instrumentation. Each monitored workflow writes a heartbeat on completion — timestamp, workflow identifier, outcome — to a single log. One line, one destination, and the uniformity is what makes the checking stage trivial.
Stage three is the check, running on its own schedule independent of the workflows it watches. This independence is essential and frequently missed: a checker built inside the same platform can fail in the same way as the thing it monitors, and a monitoring system that dies with its subject is worse than none.
Stage four is the comparison: for each monitored workflow, runs in the window against the declared expectation. Below the floor is the alert that matters. Above the ceiling is also worth flagging, because a workflow running two hundred times when it should run eight usually means a loop or a duplicate trigger, and those are expensive in a different way.
Stage five is the alert, pushed to a channel a human already reads daily. Not a dashboard — a dashboard requires the act of going to look, and that act is exactly what the founder's week does not reliably contain.
The architecture, part two: correctness and the estate review
Stage six is correctness checking, and it only goes on paths where quietly wrong is expensive: anything touching money, anything client-facing, anything writing to a system of record.
The pattern is a reconciliation rather than an assertion. Count the things that should have been processed and the things that were, and alert on the difference — invoices raised against payments recorded, signups received against onboarding sequences started. Reconciliation catches half-runs and partial writes, which are the failure mode that produces corrupt data nobody discovers for months.
Stage seven is the weekly heartbeat summary for the top-priority paths: what ran, how many times, anything outside expectation. It takes a minute to read and it converts the estate from an act of faith into something with a pulse. Founders consistently report this as the single most reassuring artifact of the whole build.
Stage eight is the quarterly estate review, run against the register: what is still running, what has not fired in ninety days, what can be removed, what has become load-bearing since it was built and now needs monitoring it does not have. This is the only stage that lets the estate shrink.
Stage nine is the incident record. When something did fail silently, record how long the gap was and which check would have caught it. That record is how the coverage improves in the places it actually needs to.
The failure edges
The first: relying on the platform's built-in error notifications. They are worth having and they are blind to the failure mode that costs most, which is a workflow that stops being triggered at all.
The second: the monitor lives inside the thing it monitors. Same platform, same account, same connection — and when the connection expires, both die together and nothing says so.
The third: alerting on everything. The fastest way to be blind is a channel with forty daily messages, because it gets muted within a week and then you have confident blindness rather than honest ignorance.
The fourth: expectations that were never revisited. A workflow whose expected volume was set at launch and has since grown will sit permanently outside its ceiling, and after a fortnight everybody stops reading its alerts.
The fifth: alerts with no owner. An alert firing into a shared channel with no named responder gets read by four people who each assume somebody else is handling it, which is a well-documented way for a silent failure to survive its own alert.
The sixth: no acknowledgement path. Without a way to mark an alert as seen and being handled, the same notification fires daily until it becomes noise, and the noise trains everybody to ignore the channel.
The register it depends on, and the order to build in
The register is the prerequisite and it is the part most businesses do not have. One row per automation: what fires it, what it does in one sentence, what it touches, who owns it, and what breaks if it stops. That last column is what lets you rank by cost of silent failure, and it is the one that never gets filled in.
Build it opportunistically rather than as an audit. An audit of forty undocumented workflows does not finish, for the same reason they were never documented. Instead adopt one rule going forward — nothing is done until it has a row — and backfill whenever anybody touches an existing workflow for any reason. The estate documents itself within a quarter, in the order that reflects what actually matters.
Then build monitoring in strict priority order: heartbeats on the top five by cost of silent failure, then the weekly summary, then reconciliation on money and client-facing paths, then the quarterly review. Attempting full coverage first is how this becomes a project that stalls at sixty percent and leaves the important paths uninstrumented.
What done looks like, and what it takes to build
Done is finding out about a broken workflow on the day it broke, from your own system rather than from a client, and being able to say at any moment which parts of the estate are covered and which are consciously not.
The checklist: a register with a declared expectation per monitored workflow; heartbeat writes to a single log; a checker running independently of the platform being watched; floor and ceiling comparison; a push alert with a named owner and an acknowledgement path; reconciliation on money and client-facing paths; a weekly heartbeat summary; and a quarterly estate review.
The build is one to two weeks for a top handful, and the ongoing discipline is that a new workflow is not done until it has a register row and, if it clears the priority threshold, a heartbeat. Retrofitting is the expensive version.
The prerequisite is the register itself. You cannot monitor an estate you cannot enumerate, and in most businesses that have been automating for three years, enumerating it is the first real piece of work.
Error alerts miss the failure that costs most: a workflow that stops being triggered. Declare an expected run frequency, check it from outside the platform, and push to a named owner.