Right now, somewhere in your business, an automation is quietly broken—and nobody’s noticed yet. The paradox? These tools save hours, but when they fail, every minute hurts. Today, we’ll walk into that silent failure and trace the first clues of what went wrong.
IDC estimates downtime costs a median of $300,000 per hour. That’s not a dramatic outage; that can be a quiet, “why didn’t that send?” gap that stalls revenue, delays follow-ups, or leaves customers hanging. The good news: most “broken” automations aren’t actually broken systems—they’re small, specific misfires you can find in minutes if you know where to look.
In this episode, we’re not rebuilding anything. We’re learning how to investigate. Think less “tear down the kitchen” and more “follow the recipe to see which step went off.”
You’ll see how a simple five-step check can turn a vague “it’s not working” into a clear, fixable issue. And instead of guessing—toggling things on and off, cloning zaps, reinstalling apps—you’ll move through a short, repeatable path that tells you exactly where the chain stopped and what to test next.
Most people respond to a “not working” alert by poking randomly at settings, turning steps off and on, or rebuilding from scratch. That’s like re-cooking an entire meal because one side dish tastes off. In reality, most issues trace back to something simple: Mulesoft found that over 60% of failures come from bad or unexpected data alone. Add in record API outages—1,754 incidents in 2023—and you can see why guessing isn’t enough.
So instead of panic-tweaking, this episode zooms in on a focused, five-minute pass: a quick way to narrow the suspect list, confirm what’s still healthy, and zero in on the one part that actually needs your attention.
Step one in the checklist: confirm the trigger actually fired. Not “it should have fired,” not “it always fires”—did it fire for this specific event? Go into your tool (Zapier, Make, Power Automate, n8n) and look for the last run. Is there a timestamp that matches when you expected something to happen? If not, you’re upstream of the problem. Common culprits: the trigger app wasn’t connected, permissions changed, or the event type you’re waiting for (like “new record” vs. “updated record”) never occurred. Fixing the wrong trigger or reauthorizing the app often restores everything without touching the rest.
If the trigger did fire, move to step two: validate the input data. Open that specific run and inspect what came in. Are the fields you relied on actually present? Is the email address blank, the status value unexpected, or the date in a different format? More than half of issues start here. If a CRM field was renamed, a form question was edited, or a spreadsheet column shifted, your automation may technically run, but with nonsense data. Correct the source (rename fields back, update mappings, or add simple data checks) so the next run has what it needs.
Step three is to inspect conditional logic or mappings. Look at filters, “only continue if” rules, and field mappings step by step. Ask: with the data from this run, would this condition be true? For example, if your rule says “Stage equals Qualified” but sales changed the label to “Sales Qualified,” that condition will quietly fail. Update the condition to match reality, or broaden it with OR logic where appropriate.
Step four: check external dependencies. If your automation calls an email API, payment processor, or internal microservice, confirm they’re reachable and healthy. A quick status page check or sending a manual test from that service can tell you whether the problem lives outside your workflow. No amount of tweaking inside your platform will fix a downstream system that’s throttling or refusing requests.
Finally, read the most recent log or alert for a concrete error. Don’t skim; match the error to the exact step and run. That “401 unauthorized” or “field_x is required” message is your shortcut from vague frustration to a specific fix.
You’re three minutes into debugging and your brain wants to jump straight to “I’ll just rebuild it.” Pause. Instead, zoom in on a single real example.
Think of a subscription business where a welcome sequence stopped sending. Someone might assume the email tool is broken. But when they pulled up a recent run, they noticed only customers on a specific discounted plan were affected. Same workflow, one edge case: that plan used a slightly different label and skipped a field the sequence depended on. Fixing one mapping and a filter rule restored hundreds of future welcomes without touching the rest of the system.
Or take a SaaS startup where invoices suddenly stopped reaching EU customers. Support thought it was a regional issue. Looking at just one failed run, they spotted a missing VAT field that only applied to that region. One conditional requirement in the billing app had changed; the automation had nowhere to put the new value. Updating the data path for that field unblocked the entire flow.
Those narrow cases show why you should always grab one concrete failure and walk the five checks in order on that, not in theory.
Future implications
Your five-minute check will soon have help. As platforms quietly learn from every fix, patterns in failures become training data: tools start nudging you toward likely root causes, much like a navigation app rerouting around traffic before you hit it. Expect suggested rollbacks, automatic quarantining of suspect inputs, and clickable “replay with patch” buttons that test a fix on past runs without touching live flows. The real skill becomes curating which assists to trust—and documenting why.
Treat this checklist like a pre-flight routine: quick, boring, and the reason flights rarely go missing. Over time, you’ll start spotting weak spots before they stall anything—odd field names, brittle conditions, flaky vendors. Your challenge this week: each time something “feels off,” run the five checks once, then note which step actually held the issue.
