Why Does My UiPath Bot Keep Breaking After Every Portal Update?
UiPath selector drift after portal redesigns, ReFramework dispatcher/performer failures, MFA walls, Orchestrator concurrency limits, and the licensing-times-latency math at 10k+ monthly runs: a UiPath-specific diagnostic with routing table and 12-month cost example.
UiPath is the most mature RPA platform on the market, which is exactly why its failure modes are so well-documented: enough bots in production, for long enough, that every breakage pattern has a name and a forum thread. If your bot broke again after the portal updated, this page routes you from symptom to fix, and gives you the math for the conversation that follows with whoever owns the automation budget.
Platform-agnostic version: why RPA bots keep breaking. Full failure arc: the anchor diagnostic.
Failure-to-fix routing table
| Failure | Root cause | Short-term fix | Long-term alternative |
|---|---|---|---|
| Selector not found after a portal deploy | Selector drift: the UI tree changed | Repair in UI Explorer, update the object repository | API integration: no selectors |
| ReFramework job stuck / transactions failing | Target app changed state mid-run | Harden transaction states, add recovery | Deterministic API calls, structured errors |
| Bot dead-ends at a 2FA prompt | Portal added MFA / conditional access | Session persistence, policy exemptions | Service accounts with real MFA handling |
| Queue depth grows, SLAs slip | Per-activity latency × volume vs robot concurrency | More unattended robots (more licenses) | Sub-second calls, no robot ceiling |
| Costs climb faster than volume | Per-robot licensing + Orchestrator tier | Consolidate workflows per robot | Per-call economics |
UiPath selector drift: "my bot stopped working after the portal redesigned"
The defining UiPath failure. Your workflow's selectors, the XML fragments UI Explorer captures, and your object repository entries reference the portal's UI tree: tag structure, attributes, indices. The portal ships a redesign, a class gets renamed, a form gets rebuilt, a table gets virtualized, and the reference points at nothing. The activity throws, the job fails, and the queue backs up overnight.
The repair loop is well-worn: open UI Explorer against the new page, re-capture or repair the selector, swap volatile attributes for stable ones, anchor against text that survives redesigns, update the object repository so every workflow inherits the fix, re-validate, redeploy. Done well, with a disciplined object repository, one drift event is a contained fix rather than a workflow-by-workflow hunt. Modern UiPath adds AI-assisted healing that sometimes rides through minor changes.
What none of that changes: an actively developed portal redesigns meaningfully 1 to 3 times a year, each break costs 4 to 16 dev-hours, and the cycle repeats indefinitely, because the thing your automation references is the thing the portal's team is paid to keep improving. The RPA overview covers why this is structural; the escape from the cycle is an integration with no UI reference at all.
UiPath ReFramework failures: "dispatcher runs, performer dies mid-queue"
The Robotic Enterprise Framework's dispatcher/performer pattern is robust right up until the target application changes state unexpectedly: a modal the workflow has never seen, a session expiring mid-transaction, the portal A/B-testing a new flow for some sessions and not others. The performer fails partway through a transaction, retry logic replays it, and now you're debugging whether the first attempt half-completed, whether the retry double-submitted, and why the exception screenshot shows a page nobody recognizes.
Hardening helps: tighter transaction boundaries, better business-exception classification, kill-and-restart browser state between items. But the underlying exposure is that a UI workflow's state machine has as many states as the portal has screens, including the ones it only shows sometimes. A backend API call has a request, a response, and a status code. Idempotency and retries are solvable problems at that layer; they are archaeology at the screen layer.
MFA and 2FA walls: "the bot hit a verification screen it can't get past"
A portal your bots have logged into for a year adds MFA, or IT rolls out conditional access that flags the robot VM's sign-in as risky. The run dead-ends at a challenge no selector can satisfy. Exemptions and trusted-location policies work until the next security review; TOTP plumbing works until the policy changes. This is the industry raising the cost of unattended credential replay on purpose, and it's the failure mode trending most strongly against RPA. The durable version, service accounts whose MFA challenges route to email and phone the integration layer owns, is how Supergood handles authentication natively.
UiPath latency at scale: "the queue can't keep up"
Every UiPath activity waits for the target UI to render: 2 to 10 seconds per step, 30 seconds for a typical login-navigate-submit workflow. One unattended robot executes one job at a time, so the latency table converts directly into licensed concurrency:
| Monthly runs | Bot time (30s workflow) | Unattended robots needed | 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 |
Licensing times execution time is the true cost at volume: each unattended robot is licensed per concurrent runtime, Orchestrator adds its platform tier, and the only way to buy throughput is more robots. Multiply your quoted per-robot annual price by the concurrency column, then compare against per-call API economics for the same workload, worked through in the true cost of browser automation past 10,000 calls a month. Latency also degrades reliability: long UI sessions time out and fail silently on dynamic portals, so the slow path is also the flaky path.
The 12-month worked example
One portal integration at 10,000 runs a month. Assumptions stated, arithmetic only: two drift breaks at 10 dev-hours, one auth change at 8 dev-hours, 2 dev-hours a month of babysitting, one dedicated unattended robot plus Orchestrator overhead.
| Cost line | UiPath (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 |
| Robot + Orchestrator | 1 unattended robot licensed year-round | No robot licensing |
| Execution per run | ~30s | ~1s |
| Total dev time | ~52 hrs/yr | ~0 after setup |
UiPath keeps its home turf: Citrix, desktop apps, SAP GUI, mainframe emulators, targets with no reachable network layer, and the decision guide is explicit about that. But a web portal has a backend its own frontend calls on every click. Supergood generates and maintains REST and MCP APIs from that layer: no selectors to drift, no robot to license, no challenge screen to click through. The head-to-head is Supergood vs UiPath, and the broader tool landscape is in UiPath alternatives for software without APIs.
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 Power Automate Desktop flow keep breaking? — the Microsoft sibling
- Supergood vs UiPath — the direct comparison
- UiPath alternatives for automating software without APIs — the alternatives landscape
FAQ
Why does my UiPath bot keep breaking? Selector drift, most often: selectors and object repository entries reference the portal's UI tree, and redesigns invalidate them. Expect 1 to 3 breaks a year per active portal at 4 to 16 dev-hours each.
What do I do when UiPath breaks after a website update? Repair selectors in UI Explorer, prefer anchors and stable attributes, update the object repository, re-validate. On the second or third recurrence, price moving the workflow off the UI layer.
Why is my UiPath bot so slow? Each activity waits on a render: 2 to 10 seconds per step. At 10,000 monthly runs a 30-second workflow is ~83 hours of bot time on a robot that runs one job at a time. The API equivalent is sub-second.
How much does UiPath cost at scale? Unattended robots are licensed per concurrent runtime and throughput is bought in robots: 100,000 monthly runs of a 30-second workflow needs 2+ concurrent robots year-round, plus Orchestrator. Multiply your per-robot quote by that concurrency.
What are the alternatives to UiPath for portal data? Official APIs where they exist; a managed network-layer integration like Supergood where they don't. Keep UiPath for desktop, Citrix, and mainframe targets.