How to Know When Your Business Process Breaks Silently (Before It Costs You)

The One That Stings

A client messaged me in March. Their contact form had stopped submitting data to the CRM. Not "sometimes." Completely. For 23 days.

They knew because a potential client had filled out the form twice, got no response, and eventually emailed directly asking why nobody had replied. That customer turned out to be a $14,000 project. They almost didn't follow up a third time.

The form was still visible on the website. No error message appeared. The submit button still worked. The webhook that was supposed to pass the data to the CRM had silently stopped firing after an API key rotation nobody had notified the automation about.

Nobody noticed for 23 days. Not the ops person. Not the sales rep. Not anyone. Because there was no alert, no dashboard, no counter that went from "something" to "nothing." Silence looks normal when you're not watching for it.

Why This Keeps Happening

Automation tools don't alert by default. That's the main reason.

Make, Zapier, n8n, they all have execution logs you can check. But you have to go looking. Unless you've configured an alert, a failed scenario doesn't send you a message. It just fails. And if the failure is consistent (every execution fails), it looks exactly like silence, which is also what zero activity looks like.

The specific failure modes worth knowing:

Webhook breaks silently. An API key expires, a third-party service updates its endpoint structure, an authentication token rotates. Your webhook stops receiving data. No error shows in your main app because the form still submits to your front end. The failure happens one step downstream, where nobody's watching.

Integration passes empty data. A field mapping breaks and a variable that used to contain a customer name now contains nothing. The scenario runs successfully, in the sense that it completes without erroring, but it's pushing blank records into your CRM or empty rows into your Google Sheet. Everything looks fine in the execution logs. Your data is quietly being corrupted.

A scheduled scenario stops running. You set up a daily report to pull numbers from your ad account and drop them in a Google Sheet. The scenario runs Monday, Tuesday, Wednesday. Thursday it errors once. The retry fails. It's now been 5 days and the sheet has old data. You think you're looking at current numbers. You're not.

A filter silently drops everything. You set a filter in a scenario to only process records where a certain field is not empty. Someone changes the form and renames that field. Now everything fails the filter and nothing processes. Zero records through. The scenario "runs successfully" every time.

All of these produce the same symptom: silence. And silence looks like "nothing to process" unless you know to look for it.

What to Check for Each Type

Webhook logs. Most webhook services have a log of incoming requests. Check it directly when something seems off. If the log shows requests arriving but nothing is processing, the issue is in your scenario logic. If the log shows no requests for a period when you'd expect them, the issue is upstream (form, app sending the webhook, API key).

In Make: every webhook has a "history" tab. Look at the timestamp of the last received payload. If it's from 3 days ago and you'd expect daily submissions, that's the signal.

In n8n: the webhook node shows execution history. You can see each incoming request, the data it contained, and whether downstream nodes processed it.

Google Sheets row counts over time. If your automation is supposed to add rows to a sheet (new leads, orders, submissions), the row count should grow in some pattern. A sheet that had 10 new rows per day for two weeks and then stopped growing is telling you something. This is easy to check manually but it's better to automate the check itself.

A simple approach: use a Google Sheets formula to count rows added in the last 7 days and compare to the 7-day period before. Drop that comparison into a daily summary email or a Slack message. If the count drops by more than 50%, something changed.

Daily email summary of automation runs. This is the single most useful monitoring habit. Every morning, a summary hits your inbox showing: how many times each key scenario ran in the last 24 hours. Not the content, just the count. Zero when you expect non-zero is an instant alert.

In Make, you can build this as a separate monitoring scenario: scheduled for 8am every day, it queries your Make API for scenario execution history from the past 24 hours, formats the count by scenario name, and emails or Slacks you the summary. Costs about 2 hours to build and runs forever.

In n8n, same approach: a scheduled workflow that queries the n8n execution API and posts a formatted count to a Slack channel. There is a prebuilt template for this in the n8n community called "n8n Execution Monitor" (version 1.3 in the community library as of earlier this year, though check for updates before using it).

Payment webhook logs. If you're using Stripe, PayPal, or any payment processor with webhook events, check the webhook delivery logs in the payment provider dashboard directly. Stripe's dashboard shows every webhook event, whether it was delivered, and whether your endpoint returned a success response. If you see delivery failures you didn't know about, you have a silent problem.

A Basic Monitoring System

Here's a practical setup that catches most silent failures without building something complicated.

The daily count scenario in Make:

Trigger: schedule, 8am every day.

Step 1: HTTP request to Make's API, endpoint /scenarios/{id}/executions, with a date filter for the last 24 hours. Repeat for each critical scenario you want to monitor. You'll need your Make API token and scenario IDs.

Step 2: Set up a threshold for each scenario. A lead intake scenario that should run at least 5 times per day has a threshold of 5. A weekly report scenario has a threshold of 1 per week, so you'd check it with a weekly version of this scenario instead.

Step 3: For any scenario where the count falls below its threshold, add it to an alert list.

Step 4: Send the summary to email or Slack. Format it something like: "Daily automation health check. All good: [list]. Needs attention: [list]."

If the "Needs attention" list is empty, the email still goes out and you know the monitoring itself ran. That's intentional. A monitoring system that only alerts on failure can itself fail silently.

The Google Sheets row count check:

In the same monitoring scenario, add a step that reads the last timestamp in a key column of each critical sheet. Compare it to "now." If the most recent row is more than 24 hours old for something that should update daily, add it to the alert list.

You can also use a dedicated formula in the sheet itself: a cell that contains =COUNTIFS(A:A,">"&(TODAY()-1)) to count rows added in the last day. A second monitoring scenario can just read that cell's value and compare it to a threshold.

Slack alert structure:

If your team uses Slack, one monitoring channel called something like #automation-health is worth having. Each morning the summary posts there. Anyone can glance at it in 10 seconds. Green means nothing to do. Any failure in the list is a thing to investigate.

The Slack Make connector sends a message in about 2 seconds. The whole monitoring scenario runs in under 30 seconds. Costs maybe 50 Make operations per day.

The Failure Nobody Talks About

Empty data passing through silently is worse than a full failure, in some ways. At least a full failure is obvious once you look at the logs. Empty data passes every validation check, creates records that look legitimate, and only shows up when a human actually opens the record and sees blank fields everywhere.

A client we worked with had this happen with their CRM enrichment workflow. A Clay enrichment step had its field mapping broken by a schema change. For 5 days, 34 company records got imported with correct names and email addresses but blank phone numbers, LinkedIn URLs, and company sizes. The sales rep called those contacts manually, didn't notice the missing data because they were used to researching manually anyway, and nothing surfaced for weeks.

When we investigated, the Make execution logs all showed "success." The scenario had technically completed without error every time. The filter that should have caught empty enrichment data had the wrong field reference.

The fix is straightforward: add a data validation step in your scenario before the "write to CRM" step. Check that key fields are not empty. If they are, route to a "failures" sheet instead of the main CRM import, and include the raw input so you can debug what came in.

A Short Monitoring Checklist

If you're running any automation that matters to revenue or client communication, go through this list once:

1. Do you know what the expected daily or weekly run count is for each critical scenario?
2. Is there any alert that fires if a scenario fails more than twice in a row?
3. Is there any check on the age of the most recent row in key Google Sheets?
4. Do you have a webhook delivery log check for any payment or booking integrations?
5. Is there a human who looks at automation health at least once per week?

If two or more answers are "no," you have silent failures you don't know about yet. That's not a prediction. It's a statistical certainty given enough time and enough integrations.

The Setup That Saves the Most

One morning email. Every day. With counts.

Not a dashboard you have to remember to check. Not a log you only look at when something seems wrong. A daily email that lands in your inbox and tells you in 10 seconds whether the systems that run your business are still running.

It takes one afternoon to build. It's probably the most valuable automation you'll add to a business that already has automations running.

If you want us to build this for you, book a free workflow audit at airtective.com