You wired two apps together months ago. It worked, so you stopped thinking about it. At some point it stopped working, and you found out when a colleague asked where something was. That gap — between the moment an automation breaks and the moment you notice — is what turns people off automating anything. This is about closing that gap before you build the automation, not after it bites you.
The verdict
Before you connect two apps, decide which of two kinds of automation you are building.
Either it is safe to fail — running it again produces the same result as running it once, re-running is cheap, and a missing output is something you'd notice within a day because you use that output. Or it needs an explicit signal: a message, on failure, delivered to a surface you already check.
Automations that are neither — one-way writes into a system you rarely open, with no signal attached — are the ones that rot. They keep their icon and their "active" toggle long after they stopped doing anything.
Why silence is the default
Automations break for boring reasons. An access token expires. An app renames a field. A rate limit trips. Someone moves a folder or changes a sharing permission. None of that announces itself.
Most automation platforms do record the failure — in a run history, a log page you'd have to open on purpose. That's a record, not a signal. No message arrives where you'd see it.
The deeper problem is that a working automation and a dead one look identical from the outside. When nothing shows up in the destination, you can't tell "there was nothing to process" from "the connection has been broken since April." Both look like quiet. Quiet is what you expected, so quiet is what you accept.
Sorting an automation before you build it
Four questions. If the answers land in the left column, you can let this one fail and fix it whenever you notice.
| Question | Safe to fail | Needs a signal |
|---|---|---|
| Run it twice? | Same result | Duplicates or double-sends |
| Output missing? | Obvious to you | Looks like normal quiet |
| Recovery? | Re-run it | Manual cleanup |
| Who reads the result? | You, often | Someone else, or nobody |
Idempotent and re-runnable
Idempotent means running the operation twice leaves you where running it once did. Syncing a calendar, mirroring a file into a backup folder, updating a status field to match a source: run these five times and the end state is the same.
These are the ones you can leave alone. If the sync dies, you re-run it and you're current again. No cleanup, no apology to anyone. Spend your monitoring effort elsewhere.
One-way writes into a place you don't open
This is the category that quietly consumes people's trust in automation. Meeting notes filed into an archive folder. Form responses appended to a spreadsheet. Receipts routed to a labeled inbox you check at tax time.
Two things are true at once here: nobody reads the destination, so nobody notices the flow stopped; and because it's a one-way write, the missing records don't turn up anywhere else. The gap only surfaces when you finally need the archive, which is the worst moment to discover it's incomplete.
You have two honest options. Close the loop — make the destination something you actually pass through, so an empty week is visible. Or delete the automation and admit you weren't using the output.
Anything with a side effect on someone else
Sending an invoice, posting to a shared channel, assigning a task, triggering a notification. Failure here costs someone else time, and re-running blindly can double-send. These get an explicit signal, no exceptions on the grounds that "it's been fine so far."
Putting the signal where you already look
An alert that lands somewhere you don't read is the same as no alert.
Route failures to a surface you already open. Your email inbox, the chat client that's open anyway, the task list you look at each morning. Not the automation tool's own notification center — that's another place to remember to check.
Report zero, not just errors. If the automation sends a short summary each time it runs — including "nothing to process" — then a week of total silence means the automation itself is dead, not that the input was empty. This is the one design change that separates "broken" from "quiet."
Make the failure block something. Put the automation's output on a path you walk for other reasons. If your weekly review pulls from the folder the automation fills, an empty folder stops you.
Watch the destination, not the run. The useful question isn't "did the job execute" but "is there anything in the place I expect." A check against the destination catches failures the automation tool never recorded, like a job that ran successfully and wrote to a folder that no longer exists.
Write down what you built and where. A broken automation you've forgotten building is a mystery. A note naming the trigger, the destination, and the account it authenticates as turns a mystery into a five-minute fix. Revisit that list when something upstream changes — a new app, a password reset, a renamed workspace.
Who can skip most of this
If you have a couple of automations and you consume their output daily, you are the monitor. A newsletter that stops arriving, a clipboard sync that stops syncing — you'll know by lunchtime. Adding alerting to those buys you little.
If your automations save a task you'd otherwise do by hand in a minute, letting them fail is a reasonable design choice. Doing it manually is the fallback, and the fallback is fine.
The care belongs where the cost of a silent failure is delayed and cumulative: archives, records, anything another person depends on receiving.
The next action
List every automation you currently have running. Beside each one, write the name of the person or the screen that would notice if it stopped this week. The ones where you can't write anything down are the ones to fix first — close the loop, or turn them off.