Spend an hour reading automation help forums and you'll see the same story over and over.
A small business sets up an automation to stop the double entry: new enquiries flow into the CRM, invoices sync to Xero, follow-up texts go out on their own. It works. Everyone forgets about it, which was the point. Then, weeks later, a customer mentions they never got the reminder. Someone goes looking and finds the automation hasn't run properly for most of a month.
There was no error message and no alert. Nothing anyone would call broken. It just stopped.
Why "no errors" doesn't mean "working"
Automations rarely fail loudly. The common causes are boring:
- A login expires. Someone changes a password or the connection times out, and the trigger never fires again.
- A field gets renamed. An app updates its form, the automation looks for a field that isn't there anymore, and it quietly skips the record.
- A filter does its job too well. Records that don't match get logged as "filtered," not "failed," so nothing looks wrong.
- The other system says no. Accounting software refuses a duplicate contact or invoice number, and the sync logs a rejection that nobody reads.
Each of these looks fine from the outside. The automation is still switched on and there are no red flags in the dashboard. It just isn't doing anything.
I wrote about this risk in Integrate or consolidate? The IT crossroads: once systems talk to each other automatically, failures go quiet, and someone has to own them. This note is about what owning them actually looks like.
Three dashboards for everything I build
Every automation I deliver comes with dashboards, and they aren't decoration. Each one answers a different question for a different reason.
1. Infrastructure: is everything running?
Every piece of infrastructure goes on one infrastructure dashboard: servers, connections, integrations and scheduled jobs. The goal is simple. You should be able to see basic system health at a glance, without opening six tools to check each one. Green means running. Anything else gets looked at.
2. KPI: is it worth having?
Every automation I build has to affect the bottom line somehow. That means time saved, money saved, more throughput, or making it possible for the business to scale without hiring at the same rate. The KPI dashboard tracks that number. This is about accountability. If an automation can't show it's paying for itself, it should be fixed or switched off, not left running because nobody checked.
3. Performance: what happened, and what needs a person?
This is the one that catches the quiet failures. For each automation it shows successes and failures, what was sent and what was received, and the exceptions that need someone to fix them. A duplicate contact Xero rejected. A form submission with a missing field. A text that bounced.
This is about responsibility. An automation can't be held responsible for its own performance, so a person has to be. That person needs to see what's going on to deal with it. If exceptions only live in a log file nobody opens, nobody is responsible for them.
A five-minute check you can do today
You don't need dashboards to find out whether this is already happening to you. Pick your most important automation and ask:
- When did it last run successfully? If you can't answer within a minute, that's your first finding.
- Who would find out if it stopped tomorrow? Name a person. "We'd notice" doesn't count.
- Where do its failures go? Check for an error log, a filtered-runs list, or a rejected-records report, and look at it.
- What is it saving you? Rough numbers are fine: hours a week or dollars a month. If you can't say, you can't tell when it stops being worth having.
If any of those answers made you uneasy, you're in good company. It's very common to find at least one automation that's been quietly doing nothing for a while.
A Systems Health Check is a good place to start. It maps what's running, what it's worth, and who's watching it before anything new gets built.