Why RPA Bots Break: Selector Drift, Portal Changes and the Real Maintenance Cost

Every RPA project demos beautifully. The bot logs into the carrier portal, pulls the tracking status, keys it into the TMS, and does in seconds what a coordinator did by hand. Everyone in the room agrees it is obvious. The business case is signed on the build cost and the hours saved.

Three months later the bot is switched off, and a person is back to doing the job. Nobody quite decided to abandon it — it just broke one Tuesday, threw an error nobody was watching, and by the time anyone noticed, the coordinator had quietly gone back to the manual process because the shipments still had to move.

This is the pattern with rule-based RPA, and it is not a sign of a bad build. It is structural. A bot automates the surface of a system — the screen, the buttons, the fields — not the system underneath. And surfaces change.

An RPA bot finds things on a screen using selectors — a reference to "the button with this ID", "the third field in this table", "the box labelled Tracking Number". Those references are only as stable as the page they point at. When the site is updated — a redesign, a new field, a renamed label, a reordered table — the selector no longer matches, and the bot either grabs the wrong thing or fails outright. This is selector drift.

The insidious part is that the website looks fine to a human. A person sees the tracking number has moved from the left column to the right and simply reads it there. The bot cannot; it was told the number lives in a specific place, and that place is now empty or holds something else. A change invisible to a person is fatal to a bot.

And drift is not a rare event. Every portal, every ERP screen, every supplier website is maintained by someone whose job is to change it. You are building automation on top of a foundation that other people are actively rebuilding without telling you.

In manufacturing, a lot of RPA runs against your own systems — your ERP, your WMS — which change on a schedule you at least know about. Freight and logistics operations are different, and harder. The bots live on other people’s websites: carrier portals, customs and port-authority sites, forwarder platforms, retailer booking systems. You do not control any of them, you get no change notice, and you cannot ask them to keep a field where it was.

A carrier pushes a portal redesign over a weekend and every bot that reads that portal is broken on Monday. A customs site adds a CAPTCHA or a two-factor step and the bot cannot pass it — nor should it, because defeating bot-detection is exactly what those controls exist to stop. A retailer changes its delivery-booking flow and your automated slot-booking silently books nothing.

This is why freight RPA has the worst maintenance profile of any automation I see. The number of external surfaces is large, the change rate is outside your control, and each break stops real shipments — so the pressure to drop back to manual is immediate.

The build cost of an RPA bot is the number in the business case. The maintenance cost is the number that decides whether it was worth it — and it is almost always left out. A bot is not a build-once asset; it is a liability that needs a named owner, monitoring, and a budget for the fixes that drift and portal changes guarantee.

Cost it honestly and the sums change. A portfolio of a dozen freight bots against external portals will need regular attention — some breaking monthly — and each fix is a developer re-recording selectors and re-testing against a live site. If nobody owns that, the portfolio degrades within two quarters: bots fail one by one, people quietly revert, and the tooling you paid for is running nothing.

The honest test before you build is not "can we automate this?" — almost anything can be automated. It is "who owns this bot in month four, and is the maintenance worth less than the manual work it replaces?" For a stable internal task, yes. For a bot scraping six carrier portals, often no.

You cannot make RPA immortal, but you can make it break far less. The first rule: prefer an API over the screen every time one exists. Most major carriers, and platforms like SAP, Dynamics 365 and modern TMS/WMS, expose APIs or EDI feeds. An integration through Power Automate connectors or a carrier API does not drift when the website is redesigned, because it does not read the website. Screen-scraping should be the fallback for systems with no other door in, not the default.

Where you must scrape, build for resilience: anchor selectors to stable attributes rather than positions, add wait-and-retry logic for slow pages, and make the bot verify it grabbed something sensible before it acts on it. And monitor every bot — the worst failure is the silent one, so each bot should report success or failure to a dashboard or an alert, so a break is caught in hours, not discovered weeks later when someone asks why the numbers look wrong.

This is also where the direction of travel matters. Newer automation blends RPA with AI — an agent that can read a page the way a person does, tolerate a moved field, and reason about an exception rather than following a brittle rule. That does not remove the need for monitoring or ownership, but it raises the ceiling on what survives a portal change. It is the subject of a separate piece, but it is the reason not to keep pouring investment into ever-more rule-based bots against unstable surfaces.

None of this means RPA is a mistake. It means RPA has a shape it fits and a shape it does not. It earns its place on a stable, high-volume, rules-clear task where no API exists and the underlying screen changes rarely — the classic internal back-office job. There, the maintenance cost is low and the saving is real and durable.

It struggles exactly where freight operations most want it: across many external portals, each changing on someone else’s schedule, where a break stops a shipment. You can still automate there, but go in with eyes open — an owner, monitoring, a maintenance budget, and a preference for carrier APIs over portal scraping wherever the choice exists.

The one-line rule I give operators: automate the boring, stable, high-volume task behind an API; be very careful automating a moving target on a website you do not own. Get that distinction right and RPA is a quiet workhorse. Get it wrong and you have bought a portfolio of liabilities that need a developer on standby.