The four reasons

In rough order of how often they cause a failure.

The interface changed. A button moved, a field was renamed, a page was redesigned. The most common by far, and cloud applications are the worst because vendors update without asking.

An unexpected popup. A survey, a cookie notice, a “new features” dialog. The automation was not expecting it and does not know what to do.

Timing. The application was slower than usual and the automation acted before the page was ready.

Credentials. A password policy forced a change, or an account was locked.

Three of the four only apply to screen automation. That is the case for using as little of it as possible.

Selectors

A selector is how an automation finds an element on screen. It is where most breakage happens.

A fragile selector relies on something that changes — position on the page, a generated ID that differs each session, or the order of elements.

“The third button in the toolbar” works until somebody adds a fourth button.

A stable selector uses something meaningful and unchanging — a name, an automation ID, a label, an accessible role.

Two habits:

Prefer identifiers over position. Always.

Use the narrowest reliable match. A selector describing the whole page path breaks when any part of that path changes. One that finds the element by its own attributes does not.

The silent failure

Worse than breaking is not breaking properly.

A selector that matches the wrong element does not error. It clicks something, and the automation carries on.

Which produces a run that reports success and did the wrong thing.

Two defences:

Verify after acting. After clicking Submit, check the page changed as expected. After downloading, check the file exists and has content.

Fail on ambiguity. If a selector could match more than one element, that is a problem to surface, not to resolve by picking the first.

Timing

The second most common cause.

The application was slower today. The automation clicked before the page was ready.

The wrong fix: a fixed pause. Wait five seconds and hope.

Too short and it still fails on a slow day. Too long and every run wastes the difference.

The right fix: wait for the element to be present and ready, with a timeout.

Faster on good days, reliable on bad ones, and when it does time out you get a clear error rather than a mysterious wrong click.

Popups

Applications interrupt. A survey, a notification, a consent banner, an update prompt.

Two approaches:

Handle known ones explicitly. If a particular dialog appears sometimes, add a step that dismisses it if present.

Handle the unknown ones structurally. Wrap the interaction so that an unexpected blocking element produces a clear error rather than a hang.

And reduce the surface. An automation that does one thing in a browser meets fewer popups than one doing twelve.

The design decision that matters most

Keep the screen-automation part as small as the problem allows.

If a process needs one step that genuinely requires a browser and eight that do not, do the one and let reliable methods handle the rest.

Then when the site redesigns — and it will — one small step needs fixing rather than the whole chain.

Concretely:

Is there a direct URL? Request it rather than navigating.

Is there an API? Use it.

Can you hand off early? Get the file, then let a workflow tool do everything after.

Every step you remove from the browser is a step that will not break.

Credentials

Three practices:

A dedicated service account, not a real person’s login. When they leave or change their password, the automation should not break.

Stored in the platform’s credential store, not in the automation itself.

Expiry tracked. If the account is subject to a password policy, know when it will force a change and plan for it rather than discovering it at 3am.

Watching for changes upstream

The proactive part, and what separates well-run RPA from constant firefighting.

Keep a list: which automations depend on which applications.

Subscribe to release notes for those applications. Cloud vendors usually announce interface changes.

Test after a known update rather than waiting for the failure.

Without the dependency list, an announced change means checking everything or nothing.

Accepting some breakage

Some fragility is unavoidable.

If you are automating against a website you do not control, a redesign will break it. No selector strategy prevents that.

What you can control:

How much breaks. Keep the screen part small.

How quickly you know. Alerts, not silence.

How quickly it is fixed. A named owner and clear logging.

Budget for maintenance. RPA is build plus upkeep, indefinitely. Companies that budget for this are satisfied. Companies that do not end up with automations nobody dares touch.

The short version

Four causes: interface changes, popups, timing, credentials. Three only apply to screen automation.

Use stable selectors, wait for elements rather than clocks, and verify after acting so a wrong click fails rather than passing silently.

But the biggest lever is design. Keep the screen part small, use HTTP requests and APIs wherever they exist, and hand off early.

You cannot stop a website redesigning. You can decide how much of your process it takes with it.