What Breaks When an Automation Runs Unattended for Six Weeks?

Why does an automation that worked on day one stop working by week six?

Because the code did not change but everything around it did. Credentials expire, upstream fields get renamed, data volume grows past a threshold nobody set, and a partial success gets recorded as a success. Nothing dramatic happens. The workflow simply drifts out from under you while the dashboard stays green.

This is the failure mode I take most seriously, and it is the reason I am wary of anyone who demos an automation and calls it done. A demo proves the happy path exists. It proves nothing about week six.

I run automations in production for real clients. Ajust runs on Airtable with WhaleSync, and that pipeline has delivered more than 25,000 cases, helped over 400,000 people, and saved upward of 50,000 hours. Kismet Health runs on HubSpot through Zapier. Those numbers only exist because somebody keeps looking at the thing, not because the thing is clever.

What actually decays, if the code never changed?

Four things, in my experience. Authentication, because tokens and app connections expire or get revoked when someone leaves. Schema, because the upstream tool renames a field. Volume, because a workflow tuned for ten records a day meets three hundred. And assumptions, because the business changed and nobody told the automation.

Authentication is the most common and the most boring. Someone rotates a password, an admin removes a departed colleague from the workspace, or a connection simply ages out. The automation does not know it has lost its hands. It keeps trying.

Schema drift is the sneakiest. A field renamed from Status to Stage does not throw an error in every tool. Sometimes it writes an empty value instead, and empty values propagate quietly for weeks before anyone notices that half the records have no stage.

How do rate limits turn into silent data loss?

Because a rejected request looks like nothing if you do not log it. Webflow's own developer documentation is clear about the shape of this. The Data API allows 60 requests per minute on Starter and Basic, 120 on CMS, eCommerce, and Business, and custom limits on Enterprise. Go past that and Webflow returns HTTP 429 Too Many Requests.

Webflow's docs say the response includes a Retry-After header telling you how long to wait, and that this reset time is typically 60 seconds. They also note that the Webflow SDK includes built-in exponential backoff, and that if you are building without the SDK you should implement retry logic that respects the Retry-After header yourself.

Read that last part again, because it is where teams get hurt. If your integration was built with a generic HTTP step in a no code tool rather than the SDK, the backoff is your responsibility. A workflow that fires thirty writes in a burst will hit the ceiling the day your content volume doubles, and unless you explicitly handle 429, those writes are simply gone. This is the same class of problem I described in the sync failure modes between Airtable and Webflow CMS, and it is the reason I always ask what happens to a record that gets rejected rather than failed.

Does automatic retry save you?

Partly, and only if you read the fine print. Zapier's help documentation says Autoreplay is available on Professional, Team, and Enterprise plans only, and is not available on the Free plan. So the safety net you assumed was there may not be there at all, depending on what your client is paying for.

There are carve outs too. Zapier's documentation states that Autoreplay will not replay safely halted Zap runs, and that in some configurations Human in the Loop steps will not autoreplay. Those are exactly the runs you most want retried, because a halt usually means something unusual happened, and unusual is where the interesting failures live.

The general principle holds across Make, n8n, and anything else you might use. Automatic retry is designed for transient faults. It does not fix an expired credential, it does not fix a renamed field, and it cannot fix a decision the workflow got wrong. Check your vendor's current documentation for what their retry actually covers, because these behaviours and plan boundaries change.

What does volume growth do to a workflow that was fine at ten records?

It converts a design choice into a bug. Sequential processing that took four seconds now takes two minutes. A polling trigger that checked every fifteen minutes now finds more records than it can process before the next poll. Batches that fit comfortably start straddling rate limits.

The tell is usually timing rather than errors. Things still complete, just later, and then later again, until one day the downstream step reads data that the upstream step has not finished writing. Race conditions do not announce themselves. They show up as one wrong record in a hundred, which is small enough that everyone assumes it was human error.

When I build something now I ask what happens at ten times the current volume before I ship it. Not because I expect ten times, but because the answer usually reveals whether I have built a pipeline or a demo.

Which failures are loud, and which are the ones that hurt?

Loud failures are fine. A workflow that stops and sends an alert has done its job. The expensive failures are the quiet ones: a step that succeeds with empty data, a filter that silently excludes everything, a deduplication rule that starts matching on a field that is now always blank.

The pattern to watch for is any step whose success condition is weaker than its purpose. A step that says it succeeded because it received a 200 response is not the same as a step that confirmed the record now exists with the right values. Those two things diverge over time, and the gap between them is where trust erodes.

I wrote separately about how to monitor for silent automation failures, and the short version is that you have to assert on outcomes rather than on status codes. Count what should exist. Compare it to what does.

What do I check on a six week review?

Five things, in order. Every connection and credential, including who owns it. The field names in every upstream source, compared against what the workflow expects. The volume trend since launch. The error and held queues, actually opened rather than glanced at. And a spot check of ten real records end to end.

That last one is not optional and it is not glamorous. I pick ten records at random, follow each one from origin to destination, and confirm the values are right. It takes twenty minutes and it catches things no dashboard shows, because dashboards report on the steps that ran, not on whether the result is correct.

The credential ownership question deserves its own mention. On client work I want to know whose account an integration authenticates as, because an automation tied to one employee's login is a resignation away from breaking. Service accounts are less convenient and far more durable.

When is the right answer to rewrite instead of repair?

When the third fix is for the same underlying cause. One patch is maintenance, two is bad luck, three means the design is wrong and you are paying interest on it. At that point the cheapest path is usually to rebuild the workflow around what you now know rather than to add another conditional branch.

The other trigger is when the workflow has grown past what the tool is good at. Visual builders are excellent up to a point, and past that point every additional branch makes the thing harder to reason about than the equivalent code would be. I have written about when to move an automation out of Zapier and into code, and the six week review is often where that decision becomes obvious.

Rewriting is not failure. Most of my best automations are second versions, built after the first version taught me what the real edge cases were. The mistake is not rebuilding, it is defending version one past the point where it earns its keep.

What should you do next?

Open the automation you trust most and check three things today: whose credentials it uses, what its error queue actually contains, and whether ten random records are correct end to end. If all three are clean, put a recurring review in your calendar and go do something else. If any one of them surprises you, you found it before your client did.

The mindset that has served me best across six years and more than 70 projects is simple. An automation is not a thing you build, it is a thing you operate. Budget for the operating, or do not build it.

If you have something running unattended that you have not looked at in a while and you would rather someone else opened the hood, reach out. I am happy to take a look and tell you honestly whether it needs a patch or a rebuild.