Why Does My RPA Bot Keep Breaking (And What To Do About It)?
Selector drift after portal updates, surprise MFA walls, per-step latency that compounds at volume, and licensing that scales against you: the failure modes shared by every RPA platform, with a routing table and the 12-month cost math for one portal integration.
Every RPA platform sells the same promise, a digital workforce that never sleeps, and every RPA program eventually staffs the same standing meeting: the one where a developer explains why the bots broke this month. This page covers the failure modes shared by every major platform, UiPath, Power Automate Desktop, Automation Anywhere, before the tool-specific guides take over. If your bot broke and you want the platform-specific diagnostic, jump ahead: UiPath, Power Automate Desktop, Automation Anywhere. For the full failure arc across browser automation too, see the anchor diagnostic.
Failure-to-fix routing table
| Failure mode | Root cause | Short-term fix | Long-term alternative |
|---|---|---|---|
| Bot fails at a step that worked yesterday | Selector drift after a portal update | Re-inspect, update the object repository | API integration: no UI reference to drift |
| Bot dead-ends at a code prompt | Portal added MFA / 2FA | Session persistence, exemption policies | Service accounts with real MFA handling |
| Queue backs up, SLAs slip | Per-step UI latency × volume | More bots (more licenses) | Sub-second backend calls, no bot ceiling |
| Costs grow faster than volume | Per-bot licensing at scale | Consolidate workflows per bot | Per-call economics without per-bot licenses |
| Attended bot works, unattended fails | Environment differences: screen, session, timing | Pin resolutions, harden the VM | Remove the screen dependency entirely |
Selector drift: "my bot broke after the portal updated"
The number-one failure mode across every platform, and the one with the most brand-specific vocabulary for the same event. UiPath calls it a selector not found. Power Automate Desktop fails to locate a UI element. Automation Anywhere throws an object-cloning error. Underneath, one thing happened: the bot holds a reference to a screen element, an XPath-like selector, an anchor, an image region, and the portal's latest deploy moved or renamed what the reference pointed at.
Object repositories and anchor-based targeting reduce the blast radius; AI-assisted "self-healing" selectors reduce it further, sometimes. None of them remove the dependency, because the dependency is the product's visual surface, and the portal's team ships to it 1 to 3 times a year in ways that matter. Each break costs 4 to 16 dev-hours: triage the failed job, re-inspect the page, update the repository, re-validate the workflow, redeploy. The cycle then repeats next quarter. This is not a defect in your platform. It is what automating pixels costs.
The structural fix is the one the RPA vs API integration decision guide walks through: an integration that talks to the portal's backend has no dependency on the UI layer, so a redesign is a non-event.
MFA and CAPTCHA surprises: "the bot hit a 2FA screen it's never seen"
RPA bots inherit a human's credentials and replay them, so they inherit the countermeasures built to stop unattended credential replay. The pattern is always the same: IT or the vendor tightens authentication, MFA, conditional access, a bot-detection layer, and a workflow that ran for a year dead-ends at a challenge screen no selector can click through. Exemption policies and session persistence postpone it; each policy review threatens the exemption.
This failure deserves more respect than it gets, because it's not drift, it's direction. Portals are systematically raising the cost of UI-replay authentication. A managed integration layer with real service accounts, where the challenge goes to an email and phone the integration owns, moves with that trend instead of against it.
Latency and throughput: "the bots can't keep up with the volume"
Even when nothing is broken, RPA carries a structural speed limit. Bots operate at the UI layer, so every step waits for a screen to render before the next action fires: 2 to 10 seconds per step, click, wait, read, repeat. That's fine at hundreds of runs a month. It stops being fine at thousands:
| Monthly runs | Bot time (30s workflow) | API time (~1s equivalent) |
|---|---|---|
| 1,000 | ~8.3 hours | ~17 minutes |
| 10,000 | ~83 hours | ~2.8 hours |
| 100,000 | ~833 hours | ~28 hours |
At 10,000 monthly runs, 83 hours of bot time collides with per-bot concurrency limits: one unattended bot is one session doing one thing at a time. The standard remedy is buying more bots, which is why RPA costs scale with volume rather than with value. And slow isn't only slow: long-running UI sessions time out, hit session limits, and fail silently on dynamic portals, so latency degrades reliability too. The equivalent backend API call is sub-second, with no concurrency ceiling tied to UI threads; the full unit economics are in the true cost of browser automation past 10,000 calls a month.
Licensing math: the cost that scales against you
Per-bot licensing means throughput is a licensing decision. The arithmetic from the table above: a 30-second workflow at 10,000 monthly runs needs ~83 bot-hours; at 100,000 runs, ~833 bot-hours, which no single unattended bot can serve, a month is only ~730 hours, so you're provisioning multiple concurrent bots plus orchestration overhead, at whatever your per-bot price is. Multiply your unattended-bot annual price by the concurrency the table implies, add the orchestrator or control-room tier, and compare it against per-call API economics for the same workload. On high-volume workflows the comparison is rarely close. The platform-specific pricing structures are covered in the UiPath, Power Automate Desktop, and Automation Anywhere guides.
Attended vs unattended: "it works when I watch it"
A bot that runs clean attended and fails unattended is meeting a different environment: a different screen resolution changing element positions, a locked or headless session changing rendering, timing differences on a loaded VM, credentials cached for the human but not the robot account. The fixes, pinned resolutions, hardened VMs, robot-account hygiene, are real work, and they maintain an elaborate imitation: a machine pretending to be a person at a desk, because the integration surface underneath was never offered. An API doesn't have a screen resolution.
The 12-month worked example
One enterprise portal, one RPA workflow at 10,000 runs a month. Assumptions stated, arithmetic only: two drift breaks a year at 10 dev-hours, one auth change at 8 dev-hours, 2 dev-hours a month of babysitting, and the concurrency math from the latency table.
| Cost line | RPA (12 months) | Supergood API (12 months) |
|---|---|---|
| Drift breaks | 20 dev-hrs | 0 |
| Auth changes | 8 dev-hrs | Handled by the integration layer |
| Babysitting | 24 dev-hrs | ~0 |
| Bot capacity | ~1,000 bot-hrs (~2 unattended bots' licensed time) | No bots; per-call API economics |
| Execution time per run | ~30s | ~1s |
| Total dev time | ~52 hrs/yr | ~0 after setup |
Where RPA keeps the case: desktop applications, Citrix, and mainframe green screens, targets with no reachable network layer. That's genuinely RPA's home turf, and the decision guide says so. But most "the bot broke again" stories are web portals, and a web portal has a backend its own frontend talks to. Supergood generates and maintains REST and MCP APIs from exactly that layer: no selectors, no sessions, no per-bot licensing, and a maintenance agent that ships fixes when the backend itself changes. The head-to-head is in Supergood vs RPA.
Related reading
- Why your enterprise automation keeps breaking — the full failure arc, all tool classes
- Why does my UiPath bot keep breaking? — UiPath-specific diagnostic
- Why does my Power Automate Desktop flow keep breaking? — PAD-specific diagnostic
- Why does my Automation Anywhere bot keep breaking? — A360-specific diagnostic
- RPA vs API integration: a decision guide — when each is the right call
- Supergood vs RPA — the direct comparison
FAQ
Why does my RPA bot keep breaking? Because it automates the UI layer: bots hold references to screen elements, and those references go stale whenever the portal redesigns, changes its DOM, or adds an auth step. The brand doesn't matter; the dependency does.
What happens when the website changes and breaks my RPA bot? The bot fails at the stale step, or acts silently on the wrong element. Recovery is re-inspection, repository updates, and re-validation: 4 to 16 dev-hours per break, 1 to 3 times a year on an active portal.
Why is my RPA so slow? Every step waits for a render: 2 to 10 seconds each. A 30-second workflow at 10,000 monthly runs is ~83 hours of bot time against per-bot concurrency limits. The equivalent API call is sub-second.
How much does RPA maintenance cost? Plan on 50+ dev-hours a year per portal integration before licensing: drift breaks, auth changes, and routine babysitting. Licensing then scales with volume because speed is bought in bots.
What are the alternatives to RPA for enterprise portals? An official API when the portal has one; a managed network-layer integration like Supergood when it doesn't. RPA keeps desktop, Citrix, and mainframe targets, where no network layer is reachable.