Why Does My Automation Anywhere Bot Keep Breaking?
A360 object-cloning errors and selector drift after portal updates, CAPTCHA and bot-detection walls, MFA surprises, Control Room concurrency limits, and consumption pricing at volume: an Automation Anywhere diagnostic with routing table and 12-month cost math.
Automation Anywhere, A360 in its current cloud-native form, runs some of the largest bot fleets in the enterprise, and fleet scale makes its failure patterns visible fast: when a portal redesign lands, it doesn't break one bot, it breaks every task that touches the portal, all at once, in the same nightly window. If your Control Room dashboard went red after a site update, this page routes you from symptom to fix. Enterprise search uses both names; so does this page: Automation Anywhere and A360 refer to the same platform throughout.
Platform-agnostic version: why RPA bots keep breaking. Full arc: the anchor diagnostic.
Failure-to-fix routing table
| Failure | Root cause | Short-term fix | Long-term alternative |
|---|---|---|---|
| Object cloning error after a portal deploy | Object drift: captured properties no longer match | Re-capture objects, prefer stable properties | API integration: no objects to capture |
| Bot blocked by CAPTCHA or challenge page | Bot detection flagged the session | Slower pacing, exemption requests | Authenticated network-layer access |
| Bot dead-ends at an MFA prompt | Portal added 2FA / conditional access | Session persistence, policy exemptions | Service accounts with real MFA handling |
| Queue depth grows in Control Room | Per-step UI latency × volume vs runner concurrency | More Bot Runners (more licenses) | Sub-second calls, no runner ceiling |
| Costs meter up faster than volume | Consumption pricing on high-frequency tasks | Consolidate and batch tasks | Per-call economics without metering |
Object drift: "A360 object cloning error after the portal updated"
The signature Automation Anywhere failure. A360 bot tasks capture target elements as objects: DOMXPath, control identifiers, image regions, coordinates. The capture is a snapshot of the portal's UI at build time. When the portal ships a redesign, renames attributes, or rebuilds a form, the snapshot no longer matches the live page, and the task throws an object-cloning or element-not-found error at the first stale step, or silently acts on whatever the loosened match found instead.
The repair loop: open the task, re-capture the affected objects against the updated page, favor stable properties (IDs, text-anchored DOMXPath) over brittle ones (indices, coordinates), and re-test the entire task, because redesigns rarely move exactly one element. A360's AI-assisted capture rides through some cosmetic churn. What it cannot change: an actively developed portal redesigns meaningfully 1 to 3 times a year, each break costs 4 to 16 dev-hours, and at fleet scale the same redesign lands on every task touching that portal simultaneously, converting one deploy into a triage sprint. The structural analysis is in the RPA overview; the exit is an integration with no UI capture at all.
CAPTCHA and bot-detection walls: "the bot gets a challenge page now"
A360 drives real browser sessions, and modern portals score those sessions: automation-shaped timing, datacenter IPs, headless-adjacent fingerprints. Cross a threshold and the portal serves a CAPTCHA or challenge page that no object capture can satisfy. Pacing delays and IP allowlisting requests buy time; both decay as the portal's detection updates.
Worth stating plainly, because RPA marketing rarely does: bot detection and RPA are the same technology war from opposite trenches, and the portal's side updates continuously. For portals your organization legitimately uses, the durable answer isn't a more human-looking bot; it's authenticated access at the network layer, where there is no browser session to score. That's the model behind Supergood, compared against the whole tool landscape in the best automation tools for enterprise portals.
MFA walls: "the bot can't get past the verification screen"
Same trajectory as every platform in this series: a portal the bots have logged into for a year adds MFA or conditional access, and the unattended run dead-ends at a challenge screen. Credential-vault integration and session persistence postpone the collision; security reviews revisit every exemption. The industry is deliberately raising the cost of unattended credential replay, and screen-layer automation is on the wrong side of that trend. Service accounts whose MFA challenges route to email and phone the integration layer owns are the version that doesn't renegotiate quarterly.
Latency at scale: "Control Room shows the queue backing up"
A360 bots execute at the UI layer: every action waits for a screen to render, 2 to 10 seconds per step, ~30 seconds for a typical login-navigate-submit task. A Bot Runner executes one task at a time, so Control Room concurrency is licensed concurrency:
| Monthly runs | Bot time (30s task) | Bot Runners implied | API time (~1s equivalent) |
|---|---|---|---|
| 1,000 | ~8.3 hours | well under 1 | ~17 minutes |
| 10,000 | ~83 hours | ~1 dedicated | ~2.8 hours |
| 100,000 | ~833 hours | 2+ concurrent (a month is ~730 hrs) | ~28 hours |
Cost times time is the number that matters: each runner is licensed per concurrent runtime, Control Room adds its platform layer, and A360's consumption-oriented pricing meters high-frequency work against you. Multiply your quoted runner price by the concurrency column, add the platform tier, and compare per-call API economics for the same workload, worked through in the true cost of browser automation past 10,000 calls a month. And as everywhere in this series, slow is also fragile: long UI sessions time out and fail silently on dynamic portals.
The 12-month worked example
One portal integration at 10,000 runs a month. Assumptions stated, arithmetic only: two object-drift breaks at 10 dev-hours, one auth change at 8 dev-hours, 2 dev-hours a month of babysitting, one dedicated Bot Runner plus Control Room overhead.
| Cost line | Automation Anywhere (12 months) | Supergood API (12 months) |
|---|---|---|
| Object-drift breaks | 20 dev-hrs | 0 |
| Auth changes | 8 dev-hrs | Handled by the integration layer |
| Babysitting | 24 dev-hrs | ~0 |
| Runner + Control Room | 1 Bot Runner licensed year-round | No runner licensing |
| Execution per run | ~30s | ~1s |
| Total dev time | ~52 hrs/yr | ~0 after setup |
A360 keeps its legitimate case: desktop applications, Citrix, terminal emulators, targets with no reachable network layer. A web portal is not that case. A web portal's frontend calls backend endpoints on every click, and Supergood generates and maintains REST and MCP APIs from exactly that traffic: no object captures to drift, no runners to license, no challenge screens to defeat. For the platform-by-platform landscape, see the best automation tools for enterprise portals.
Related reading
- Why your enterprise automation keeps breaking — the full failure arc
- Why does my RPA bot keep breaking? — the platform-agnostic view
- Why does my UiPath bot keep breaking? — the UiPath sibling
- The best automation tools for enterprise portals — the ranked landscape
- The true cost of browser automation past 10,000 calls a month — the cost model
FAQ
Why does my Automation Anywhere bot keep breaking? Object drift, most often: A360 captures target elements as property snapshots, and portal redesigns invalidate them, throwing object-cloning errors. Expect 1 to 3 breaks a year per active portal at 4 to 16 dev-hours each.
What do I do when A360 breaks after a website update? Re-capture the affected objects, prefer stable properties over coordinates, re-test the whole task. On the second or third recurrence, price moving the workflow off the UI layer.
Why is my Automation Anywhere bot so slow? Every action waits on a render: 2 to 10 seconds per step, one task per Bot Runner at a time. At 10,000 monthly runs that's ~83 hours of bot time; the API equivalent totals under 3 hours.
How much does Automation Anywhere cost at scale? Runners are licensed per concurrent runtime and consumption pricing meters high-frequency work: 100,000 monthly runs of a 30-second task needs 2+ concurrent runners year-round plus Control Room. Multiply your runner quote by that concurrency.
What are the alternatives to Automation Anywhere for portals? Official APIs where they exist; a managed network-layer integration like Supergood where they don't. Keep A360 for desktop, Citrix, and terminal targets.