Keeping an Automation Alive After the Tool Underneath It Changes

How do I keep an automation working when the tool underneath it changes?

Treat every vendor as a moving part. Write down which tools your automation depends on, what each one is doing for you, and what you would switch to if it changed. Then check that list on a schedule instead of waiting for something to break in front of a customer.

Across the automations I have run in production, the ones that died did not die from bad logic. They died because a tool changed underneath them. A pricing tier moved. A model retired. An endpoint started returning a slightly different shape. The automation kept running and kept being wrong.

That is the part people underestimate. A broken automation announces itself. A changed automation does not.

What actually changes under an automation?

Four things change: prices, limits, model or API versions, and default behaviour. Prices change what you can afford to run. Limits change how much you can run. Versions change what comes back. Default behaviour changes what happens when you do nothing, and that last one is the most dangerous because nobody sends an email about a default.

Prices are the easiest to see. Anthropic's pricing documentation lists Claude Opus 5 at five dollars per million input tokens and twenty five dollars per million output tokens, Claude Sonnet 5 at two dollars and ten dollars, and Claude Haiku 4.5 at one dollar and five dollars. Those three numbers decide whether a content pipeline is a rounding error or a real line item.

Limits are the second. Zapier's pricing page describes task tiers and says that if you reach your limit you will be switched to pay as you go unless you turn it off or move up to a higher tier. That is a sensible default for a business and a surprising one for a bill, and it is exactly the kind of behaviour worth knowing before a busy month rather than after it.

Which changes break things quietly instead of loudly?

Quiet changes share one property. The automation still completes. A model swap that returns slightly different formatting still returns something. A field that starts arriving empty still arrives. A retry that silently drops a record still reports success. Loud failures page you. Quiet failures accumulate in a database nobody reads.

The Ajust automations I run on Airtable and WhaleSync have delivered more than twenty five thousand cases, and the thing I watch hardest is not uptime. It is shape. Are the records arriving with the fields I expect, in the format I expect, at roughly the volume I expect. Uptime tells you the pipe is open. Shape tells you the right thing is going through it.

This is why I think monitoring belongs in the build, not in the backlog. I wrote about the specific patterns in my piece on catching silent automation failures, and the short version is that you should alert on absence and on anomaly, not only on errors.

What does a model price change do to a working automation?

It changes the economics without touching the logic. An automation that made sense at one price can stop making sense at another, and the code will happily keep running either way. So the useful habit is knowing which of your automations are price sensitive before a price moves, not after you read the bill.

There is a good recent example. Anthropic's pricing documentation notes that the two dollar and ten dollar per million input and output token pricing for Claude Sonnet 5, announced at launch as introductory pricing through August 31, 2026, is now the standard price, and that the previously scheduled increase to three dollars and fifteen dollars will not occur. That is a change in your favour, and it is still a change you want to notice.

Changes in the other direction happen too. The same documentation lists Claude Haiku 3.5 and Claude Sonnet 4 as retired except on Amazon Bedrock and Google Cloud. If an automation of yours pins an old model by name, retirement is the change that ends it.

My rule is that any automation calling a model should name the model in exactly one place in the configuration. If you have the model name scattered across nine steps, a swap becomes a migration.

How do you find out about a change before your automation does?

Subscribe to the primary sources and nothing else. Vendor changelogs, release notes, status pages, and pricing pages are where changes are actually announced. Newsletters and social posts are downstream, late, and sometimes wrong. Put the real pages on a monthly review and read them yourself.

For the tools I depend on, that means the Webflow updates page, Anthropic's model documentation, the Zapier pricing page, and the changelogs for Airtable, WhaleSync and HubSpot. It takes less attention than a single support ticket, and it has repaid that attention many times over.

The second habit costs nothing. When you build an automation, record the date you last confirmed each dependency's behaviour. Six months later, that date tells you which assumptions are stale. An undated assumption feels equally true forever, which is how people end up surprised.

What should you write down so a change is cheap to absorb?

Write down the dependency list, the shape of the data at each boundary, the model or plan each step assumes, the rough monthly volume, and the person who owns the fix. Five short sections. If a new tool has to be swapped in, that document is the difference between an afternoon and a fortnight.

I keep this in the same place as the runbook, because the two questions come up together. What does this do, and what does it depend on. My longer take on the first half lives in what to write before you ship an automation, and the dependency list is simply the section most people skip.

The shape section matters most. Write one example record at every boundary, with real field names and a realistic value. When something changes, you compare today's record against that example and you see the difference in seconds. Without it you are reasoning from memory about what the data used to look like, and memory is generous.

How do you test a swap without risking real data?

Run the new version beside the old one on the same inputs and compare outputs before you switch anything. Send nothing to production systems during the comparison. Write both results to a scratch table, look at a few dozen records by hand, and only then move the live automation across.

For the Kismet Health work, where records move into HubSpot through Zapier, the thing I care about is that no bad record ever reaches the CRM, because cleaning a CRM is far more expensive than delaying a sync. A parallel run protects that. Cutting over and watching does not.

Make the comparison boring and specific. Count the records. Check the empty fields. Check three records you already know the correct answer for. If you cannot state what a correct output looks like before you run the test, you are not testing, you are hoping.

When is the right answer to rebuild instead of patch?

Rebuild when the change hits the assumption the whole thing was designed around, not just a step inside it. If a tool's pricing model, data model, or execution model has moved, patching produces something fragile that nobody understands. If only an endpoint or a field name moved, patch it and move on.

I apply a rough test. If I cannot explain the patched version to a client in two sentences, the patch was the wrong call. Automations earn their keep by being explainable. The moment one becomes a pile of exceptions, its real cost stops being the subscription and starts being the attention it demands.

There is a related decision about leaving a platform entirely, which is a different question with a different answer. I worked through it in moving an automation from Zapier to code, and the honest summary is that most teams move too late for the wrong reason, which is frustration rather than economics.

What should you do next?

Pick your most important automation today and spend thirty minutes writing its dependency list, its data shapes, and the date you last confirmed each one. Then put a monthly reminder on the changelogs and pricing pages of the tools it needs. That is the whole practice, and it is cheap.

Everything else in automation maintenance follows from knowing what you depend on. Teams that keep that list current absorb vendor changes as small chores. Teams that do not discover their dependencies during an outage, which is the most expensive time to learn anything.

If you have an automation running quietly in your business and you are not sure what it would take to survive a tool change, send me a description of it. I will tell you honestly where the fragile parts are.