Software robot maintenance: what does it cost?

Maintaining a software robot is all the work needed to keep it running reliably after go-live: monitoring, handling failed runs, adjusting it when an application or the process changes, and keeping passwords, licences and the robot software up to date. How much that costs depends mainly on how often the applications that the robot operates change, how many exceptions the process has and how well the robot is built and documented. A fixed percentage of the build costs says little about this. It is better to calculate per part, as below.

What maintenance involves

A software robot is not an industrial robot: it works through the screens of other applications, as an employee does. It therefore depends on everything that changes in those applications and on its own machine. Maintenance consists of these parts:

Parts of the maintenance of a software robot
Part	What happens	Can you plan it?
Monitoring	Checking every day whether the runs succeeded and whether all cases were processed	Yes, routine work
Handling failed runs	Finding the cause, restarting the robot, having cases processed again	No, it varies
Changes in applications	Testing and adjusting the robot after a screen update	Only if the supplier announces updates
Passwords and certificates	Renewing an expired password of the robot account or an expired key	Yes, if the expiry dates are known
Licences	Renewing subscriptions and adjusting the number to the volume	Yes
Platform upgrades	Updating the robot software and the machine to a supported version	Yes
Process changes	A customer changes their order file, a check changes	Partly
Small improvements	A clearer alert, an exception that is handled automatically from now on	Yes, as a fixed budget

Agree what counts as maintenance and what counts as a change. Maintenance keeps what exists working: getting the robot to run again after a screen update, or recognising the file of an existing customer again. A change adds something, such as a new customer with its own file format or a second process, for example copying bills of materials (the parts of a product) from the PDM system (for drawings and revisions) into the ERP (the business system for orders and administration). You can read how changes fit into the budget in what it costs to automate a business process.

Why a robot that works through screens needs more maintenance than an integration

A robot recognises a field or button by attributes of the screen. UiPath calls that description a selector. According to the UiPath documentation, a selector no longer finds the element if an attribute gets a different value every time the application starts. For some web applications with a changing structure, the developer must create selectors by hand. For Power Automate, Microsoft names even more causes for a selector to fail: updates and screen changes in the application, a different screen resolution or scaling, a different Windows version, a different window size and different user permissions. How that difference works out when you choose a technology is in RPA or API integration: which is the best choice?

For maintenance, this counts most: a screen is made for people. The supplier may change it without warning anyone. An employee adapts without effort, a robot does not adapt by itself. Both large platforms therefore assume that screens change. UiPath lets you store screen elements in a library, so that you update the selectors in one go after a new version of an application. For Power Automate, Microsoft recommends collections of screen elements: after an update, you adjust the collection once, and all desktop flows that use it take over the change.

An integration through an API (a fixed entry point that lets software talk to other software) is an agreement between the supplier and other software. It also changes, but usually with versions and an announcement. For example, Microsoft marked version 1.0 of the Business Central API as deprecated in 2024 and removed it in 2026 (release wave 1, version 28.0). Anyone with an integration on that version had to migrate, but knew this two years in advance. An integration also needs its own maintenance: keys and certificates expire, and the integration must deal with limits on the number of requests. For example, Business Central returns an error code when there are too many requests, and the integration must then try again later.

Maintenance per approach compared
Approach	What maintenance involves	Sensitive to	Advance notice
Excel with Power Query (getting and transforming data) or a macro	Adjusting the query when columns change	A different file layout; the maker leaving	Rarely
Software robot through screens	Testing and adjusting selectors after updates; renewing passwords	Screen changes, slow screens, new login steps	Sometimes through release notes; often not for web portals
Integration through an API	Monitoring, renewing keys, moving to a new API version	New versions, limits, expired keys	Often, through versions and a deprecation schedule
Standard import of the ERP	Keeping the import file in line with the format	A changed import format	Through the ERP supplier

Worked example: a year of maintenance for an order robot

Example (illustrative)

A manufacturing company receives 80 orders by email every working day, as a PDF or as an Excel file. An unattended software robot (unattended RPA) reads the mailbox, takes the data from the attachment and enters the order through the screens in the ERP system. Such a robot starts automatically and runs on its own machine, without an employee having to be present. It follows predefined rules. On an error or exception it can stop, send an alert or put the case to an employee. The run stays traceable. It puts the 15% of orders with an exception (12 per day), with the reason, in a review queue for the inside sales team: the list of cases that an employee reviews. Every day, an employee checks for 15 minutes whether all orders have been processed.

Assumptions for the year of maintenance: the ERP gets two major updates per year, the password of the robot account expires every quarter, three existing customers change their order file, and the robot software gets one upgrade. All figures are assumptions.

Worked example (illustrative): maintenance hours of the administrator in one year
Part	Assumption	Hours per year
Handling failed runs	2 times per month, 30 minutes	12
Renewing the password of the robot account	4 times per year, 30 minutes	2
Testing and adjusting for a major ERP update	2 times per year, 6 hours	12
Customer changes their order file	3 times per year, 3 hours	9
Updating and retesting the robot software	1 time per year, 8 hours	8
Small improvements	Fixed budget	5
Total		48 hours, on average 4 hours per month

These 4 hours per month are the same maintenance hours as in the budget in the costs article. Two items are not in the table. At 230 working days, the daily check by the inside sales team takes about 58 hours per year. That is time of your own employee, and you subtract it from the time that is freed up, as in the calculation of the return. In addition, the licences and the machine are ongoing costs.

What the table does not show is the spread. In a quiet year, it stays at this. But a web portal that gets a new screen without notice, or an ERP update that changes order entry, can take more hours in one month than this whole annual budget. So reserve a buffer next to the fixed hours, and agree how it is charged.

What determines the maintenance costs

The number of applications that the robot operates. Each application has its own update moment and its own login. A robot that operates the ERP, the PDM system and a customer's portal follows three update moments.
How often those applications change. An ERP with a fixed release schedule is easier to follow than a customer's web portal that changes without notice. Business Central online, for example, gets two major updates every year, in April and October, and a minor update in the other months.
The number of exceptions and variants in the input. Each variant is a place where a change can make the robot stumble.
The quality of the build. A robot that reports exactly where it stopped after a failure costs less searching than a robot that only reports "failed".
The login policy. Passwords that expire often and two-step verification make unattended work harder and need more management.
A test environment. Without a test environment, you test updates in the live environment, with extra checks and more risk.
The required response time. Must a failure be fixed within an hour, or can it wait until the next working day? Fast availability costs more, also in months without failures.
Documentation. Someone who did not build the robot must be able to understand it. Without documentation, every failure starts with finding out how the robot works.

How to keep maintenance low

Robust selectors and central screen elements

UiPath advises building selectors on attributes with a fixed value. Microsoft advises the same for Power Automate, plus fallback selectors for when the first selector does not find the element, and a retry policy in the error handling. Also store screen elements centrally, in a library or collection. Then you adjust a changed screen in one place, and not in each process separately.

Error handling that makes a distinction

UiPath distinguishes between a technical error, such as an application that does not respond, and an error in the data, such as a phone number with a missing digit. With a technical error, a new attempt makes sense. UiPath Orchestrator (the management program that starts and tracks robots) retries such a case automatically if this was set when the queue was created. By default, Orchestrator does not retry an error in the data. That error belongs with a person, with a clear reason. A robot that makes this distinction solves part of its failures itself and sends the rest to the right person.

Work with a queue

In a queue, each case, for example an order, is a separate item with a status. In UiPath Orchestrator, you see per item whether it succeeded, failed or was retried. An item that stays in progress for about 24 hours without being processed gets the status "Abandoned". This way, you immediately see which orders are stuck, instead of having to search for them.

A meaningful log

Let the robot record which case it processes, in which step and with which result. In UiPath, your own messages from the Log Message activity go to the Logs page of Orchestrator. There you filter by level, from Trace to Fatal. A message such as "Order 4711: drawing 123 has revision B, released is C, moved to review queue" saves a lot of searching when there is a failure.

Passwords and keys in one place

Do not put login details in the robot itself. In UiPath Orchestrator, they can be stored centrally as an asset of the type Credential, encrypted in the database. Different processes can use the same asset. If a password expires, you change it in one place. Also put the expiry dates of passwords, certificates and keys in a calendar. For example, Microsoft limits the validity of a client secret (a password for an application) in Microsoft Entra to at most 24 months, and recommends less than 12 months.

A test environment and the release notes of your applications

Test an update in a test environment first, before it reaches the live environment. Follow the release schedule and the release notes of the applications that the robot operates. Then you know when an update is coming, and you can test the robot in advance instead of repairing it afterwards. Some suppliers make that easy. For a major update of Business Central, Microsoft offers a preview version in a test environment about a month in advance, and strongly recommends testing the most important processes before the live environment is updated.

Keeping the robot software up to date

Plan upgrades of the platform. For the products that you install yourself (on-premises), UiPath gives an LTS version two years of mainstream support and then one year of extended support. After that, support stops for most customers, and you must upgrade to get help again. An upgrade itself also needs attention. Microsoft states that Power Automate for desktop is backward compatible, but that an update can change actions, and that a flow made with a newer version is not guaranteed to work on an older version. So keep the version on the build machine and on the robot machine the same, and test after every upgrade.

Documentation

Record what the robot does and does not do, which accounts it uses, where the log is and what someone must do when there is a failure. That way, someone else can also maintain the robot.

What a maintenance agreement must cover

What is included. Monitoring, fixing failures, adjusting after updates, renewing passwords, platform upgrades. And what is not included: new functions and new processes.
Who monitors. Does the administrator check every day, or your own employee? Who gets the alert when there is a failure?
Response times. Within what time does someone start work on a failure, on which days and between which hours?
How you pay. A fixed number of hours per month, a bundle of hours or per incident. Fixed hours give predictability. Paying per incident is cheaper in quiet months and more expensive in busy ones. Record what happens with hours that are left over or fall short.
Your duty to report. Let the administrator know in time when an application gets an update or the process changes.
Licences. In whose name are they, and who renews them in time?
Testing for updates. Who tests, in which environment, and who gives approval?
Access and ownership. You keep access to the robot, the source code, the accounts and the documentation, also if the collaboration stops.
Continuity. Who takes over when the administrator is ill or on holiday? With a small supplier or one internal developer, that is a real question. Good documentation and your own access are then the insurance.
Handover. How does the administrator hand everything over if you stop or switch?

Decision framework

Questions to ask internally

How often do the applications that the robot uses change, and who hears about it first?
Who checks every day whether the robot has done its work?
How fast must a failure be fixed: within an hour, or the next working day?
Is there a test environment for the most important applications?
Is there an API that can replace part of the screen work?

What weighs most

How often the applications change, and how well the robot is built. A robot on a stable ERP, with good error handling and a log, needs little maintenance. A robot on a web portal that changes often, without a log, needs a lot, however cheap the build was. If maintenance stays structurally higher than expected, investigate whether an integration can take over the screen work.

When outside help makes sense

If nobody internally has time to monitor every day and fix failures. Or if the developer has left and the robot is not documented. Then first have the robot reviewed: is it easy to maintain, or is rebuilding it cheaper? You can see what maintenance after go-live involves on the services page, under maintenance and support.

Honest about the limits

Maintenance stays necessary. Even a well-built robot depends on screens that someone else manages. Some changes come without notice, and then the robot stands still until someone adjusts it. A robot without an owner can break at the first change, sometimes without anyone noticing immediately. That is one of the known reasons why RPA projects fail. So include maintenance in the business case from the start, as a fixed item next to the licences.

What does maintaining a software robot cost?