Why do automations stop working?

Usually it's because someone else changed their software. Almost every automation depends on other companies' programs, and those companies regularly update, restrict or retire the ways other software is allowed to connect to them, sometimes with years of warning and sometimes with a few weeks.

That isn't a reason to avoid automation. It's a reason to know that an automation isn't something you build once and forget. It's something you own. It sits on top of two, three, sometimes six other companies' software, and any one of them can change something at any time.

What is an API, and why does it matter here?

An API is a service counter that a piece of software keeps open for other programs: they walk up, ask in the agreed format, and get an answer. We've explained it properly, with a worked example, in what APIs and MCP are. What matters here is that every automation is a series of trips to other companies' counters, and each company sets its own rules for how its counter works.

Those rules come in versions, a bit like editions of a rulebook. Now and then a company publishes a new edition and eventually stops honouring the old one. What happens then varies, and it isn't always obvious.

Meta's Graph API documentation, the rules for software connecting to Facebook, is unusually direct about it: for its APIs, "once a version is no longer usable, any calls made to it will be defaulted to the next oldest, usable version." In plain terms, the automation doesn't stop and doesn't show an error. It carries on, answered under rules you didn't choose, and nothing tells you.

Most changes are announced well in advance

The good news is that most changes are. Meta's stated policy is that "each version will remain for at least 2 years from release", and that "a version will no longer be usable two years after the date that the subsequent version is released". Its changelog lists every available version, the date it came out and, once it's been set, the date it stops working, much like a train timetable.

Microsoft gives even longer. On 19 September 2023 it announced that it would start blocking Exchange Web Services requests from non-Microsoft apps to Exchange Online on 1 October 2026. Exchange Web Services is an older counter that other programs use to reach Microsoft business email. That was three years' notice, for something Microsoft had already said in 2018 would get no further feature updates. Its current timeline set October 2026 as the month it started being switched off for all organisations, and April 2027 as when it's fully switched off.

Xero follows the same pattern on a shorter timescale. On 6 August 2026 it announced that the broad permissions on its Accounting API are being replaced with narrower ones. Think of it as swapping one master key for a keyring: the single accounting.transactions permission is being split into separate permissions for invoices, payments, bank transactions and manual journals. Apps created on or after 2 March 2026 already use the new permissions, and everything older has until 13 September 2027. That's roughly thirteen months' notice on a change to how your automation proves it's allowed to see your books.

None of these are surprises. They're all published. The difficulty is that somebody has to be reading, and whoever built your automation in March probably isn't still checking the Xero announcements in November.

If keeping an eye on those announcements is the part nobody has time for, that's exactly what our ongoing support is for, and we're happy to look after the automations we set up for you.

Some changes arrive within weeks

Others come with much less warning.

On 29 May 2025 Slack moved two of its most-used API methods, conversations.history and conversations.replies, which are the ones any tool uses to read what was said in a channel, from its Tier 3 rate limit to Tier 1. A rate limit is like a shop counter that will only serve so many customers a minute. Tier 3 is documented as "50+ per minute" and Tier 1 as "1+ per minute". The published new limit is one request per minute, returning at most fifteen items. It applied straight away to new apps and to new installations of existing ones. Installations already in place weren't affected.

Two things about this are worth noting. First, it wasn't an outage. Nothing obviously broke. Anything using those methods carried on working, but far more slowly and with far less information. A tool summarising a busy channel every morning would keep producing a summary. The summary would just be incomplete.

Second, it didn't affect everyone. Slack exempted internal apps a company builds for its own use, which keep 1,000 items per request at 50-plus requests a minute, and apps approved for Slack's Marketplace were unaffected. The change was aimed at commercially sold tools that hadn't been through Slack's review. So a business that had set up its own Slack automation was fine. One that installed a third-party tool after that date might not be, and had no easy way of knowing which side of the line its supplier was on.

That's true more generally. You're rarely exposed to the big platform directly. You're exposed to whoever sits between you and it.

Xero, meanwhile, has switched some things off completely: its Accounting Activities API was retired in May 2026 and three Practice Manager endpoints in August 2026, and both now return errors.

Sometimes there's no way to switch it back on

Basic authentication was the old way for programs to log in to Microsoft email with just a username and password. Microsoft's page on retiring it contains a sentence worth reading twice: "Before December 31, 2022, you could re-enable the affected protocols if users and apps in your tenant couldn't connect. Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant."

That doesn't mean raising a support ticket. It means nobody can. Microsoft announced it well in advance, switched it off for accounts that weren't using it from early 2021, applied it to everyone else from 1 October 2022, and left a grace period until the end of that year in which you could turn it back on while you fixed things. Then that option was removed. Years of notice and a grace period is about as fair as a supplier gets, and it still ended with rebuilding as the only way forward.

Why is a silent failure worse than a loud one?

An automation that shows an error is a nuisance, but someone notices and it gets fixed. An automation that quietly stops working costs more, and the cost builds up, because the whole reason you automated the job is that nobody does it by hand any more.

Think about the jobs people tend to automate first: chasing overdue invoices, copying website enquiries into a customer list, recording bank transactions. Each one is a job you stop checking precisely because it now happens on its own. If invoice chasing quietly stops in October, you might not find out until January, when the list of who owes you money looks wrong and three months of unchased debts have built up.

Most of the changes above lead to quiet failures. An expired version that falls back to another still returns answers, just under different rules. A tighter rate limit still returns information, just less of it. Only a complete switch-off is loud, and that's the least common.

So the principle is simple, if unexciting. Something needs to notice, and what it should check is the result, not just the connection. "Did the connection work?" tells you very little. "Did thirty-one reminder emails go out this week, when the usual range is twenty to forty?" catches a silent failure. Choose the number that would look wrong if the automation stopped working properly, and have something check it regularly. That doesn't need a special monitoring product. It needs a written note of what normal looks like, and an alert that reaches a person.

If you'd like that kind of check built in from the start, we're happy to set up an automation that watches the results and tells a person when the numbers look wrong.

Keep anything that handles money short and simple

The second decision is about where the risk sits. Count the steps. An automation that reads your website form and adds a row to a spreadsheet depends on one supplier who might change something. One that reads the form, looks up extra details through a data service, adds them to a customer system, triggers an email platform and updates your accounts depends on five, each with its own rules for retiring things and its own reasons to restrict access. The chain is only as reliable as its weakest link.

That isn't an argument against longer chains, but it is an argument for knowing which link matters most. If an automation handles money, such as invoices, payments or anything that creates income or a legal obligation, keep it as short and simple as you can, and make sure a person could do the job by hand for a fortnight if needed. If an automation saves twenty minutes a week on internal admin, it's fine for it to be more fragile. If it fails, it's an inconvenience rather than a problem.

What should you do next?

If you have one or two automations and someone looks at what they produce every day, you already have a check in place, and there's nothing to buy. Just write down, in a line each, what each one connects to and which number would look wrong if it stopped.

If you have automations nobody looks at any more, it's worth spending an hour listing them: what each one connects to, what it does, and who would notice if it stopped. You may well find one that quietly stopped working some time ago, so start there.

If any of them handle money, check whether the supplier publishes a list of changes and whether anyone in your business reads it. Xero, Microsoft, Meta and Slack all publish theirs openly. Reading four of those a month isn't difficult, but it's easy for it to become nobody's job.

This is, honestly, an argument for having someone keep an eye on it for you, and we'd rather say that plainly. But it holds whether you use anyone or not. Building an automation is the cheaper part. Looking after it is the real ongoing cost, and a quote that doesn't mention it only covers half the job. If you'd like to talk about setting up automations that are looked after once they're running, get in touch.

Sources

• Graph API versioning and the Graph API changelog - Meta
• Retirement of Exchange Web Services in Exchange Online - Microsoft 365 Developer Blog, 19 September 2023
• Deprecation of Exchange Web Services in Exchange Online - Microsoft Learn
• Deprecation of Basic authentication in Exchange Online - Microsoft Learn
• Rate limit changes for non-Marketplace apps and Web API rate limits - Slack
• Xero developer changelog - Xero

Checked on 23 October 2026. Deprecation timetables move: vendors extend deadlines, and occasionally bring them forward. Verify any date here against the vendor's own changelog before you plan around it.