How to Build a Maintenance Plan for Business Automations

An automation that sends invoices, updates stock or creates a customer record feels finished the day it works. Then, quietly, the world around it changes. A supplier changes the format of a file. A software vendor updates a connection. The person who built the flow leaves. A password expires. A new product code does not match the lookup table. The automation keeps running, or appears to, and the business only learns of the damage when a customer calls.

A maintenance plan is the routine that catches those changes early. It does not have to be elaborate. For most small and mid-sized businesses, it is a list, a calendar and a few agreed habits. This article sets out how to build one.

Why automations need upkeep

Automations depend on things they do not control: other software, other people's data, networks, credentials and rules. When any of these changes, the automation may fail loudly, which is easy to fix, or silently, which is not. The business consequences of the second kind are explained in how silent automation failures damage operations. The cost comparison is also in your favour: recurring systems maintenance is cheaper than emergency repair.

There is also a budget problem. Many businesses pay for the build and forget the upkeep, a pattern described in why new SaaS integrations have no maintenance budget. A maintenance plan makes that cost visible and puts it in the annual budget, where it belongs.

Step 1: Make an inventory

You cannot maintain what you cannot list. Create one sheet with a row for every automation, and record the following for each:

What it does, in one sentence.
Which systems it reads from and writes to.
Where it runs, and under whose login.
Who built it and who owns it today.
How important it is: what stops, and what it costs, if it fails for a day.
The date it was last checked and last changed.

Look in unlikely places: email rules, scheduled spreadsheet macros, connections built inside accounting or CRM software, and tools bought by individual departments. Anything run on a person's own credentials deserves a flag, since it will stop the day that person's account changes.

Step 2: Name an owner and a deputy

Every automation needs a named person responsible for it, plus a stand-in. Ownership means being the person who is told when it breaks and who decides what to do. Without this, maintenance becomes everybody's job, which means nobody's. The reasoning appears in who watches the automations.

Step 3: Rank by consequence

Sort the inventory into three tiers. A critical automation affects money, customers or compliance, such as payroll exports, invoicing and customer notifications covered by the Protection of Personal Information Act. An important one saves significant time but has a workable manual fallback. A convenience tool is nice to have. The tiers decide how often you check each one, and how quickly you respond. Do not spread effort evenly: forty convenience automations deserve less of your attention than two critical ones.

Step 4: Set up health checks

A health check asks a simple question at regular intervals: is it working? Microsoft's guidance on health endpoint monitoring describes functional checks that tools can run at regular intervals to verify that a service and its dependencies can serve requests, with the results used to detect degraded or unavailable components. You can borrow the principle without writing any code. For each critical automation, define a visible sign of life: a daily summary message with the count of records processed, a log entry that a named person reads each morning, or a test record that should appear at a known time.

Watch the business outcome, not just the technical run. An automation can execute successfully and still do nothing useful, for instance sending zero invoices because an input file was empty. Guidance on what to track is in what should you monitor in an automated business process, and on alerting in how to design alerts for automation failures.

Step 5: Decide how failures are handled

Some failures fix themselves if you try again. Microsoft's retry pattern notes that transient faults, such as a momentary loss of connectivity or a busy service, are typically self-correcting, so repeating the action after a suitable delay is likely to succeed, and that if the operation still fails after a set number of attempts it should be treated as an exception. Its circuit breaker pattern adds that repeatedly calling a service that is down wastes effort and can make matters worse, so calls should stop for a time. In everyday terms, your plan should state how many retries are acceptable, what happens after that, and who is alerted. With load-shedding interrupting connections at predictable times, a sensible retry rule can prevent many unnecessary call-outs. Beware of retries that create duplicates, such as a second invoice. The point is also made in automations break when application interfaces change.

Step 6: Build a review calendar

Put the routine checks into a calendar so they happen whether or not anything has gone wrong.

Daily or weekly, for critical automations: read the summary, confirm counts look sensible and clear any exceptions.
Monthly: review failed or retried runs, expiring credentials and certificates, and any vendor notices of upcoming changes.
Quarterly: confirm each owner is still in the business and in the same role, test the manual fallback for critical items, and look for automations that nobody uses.
Annually: revisit the tiers, the inventory and the budget, and ask whether each automation still matches how the business works.

Step 7: Change things safely

Most breakage comes from changes, not from age. Microsoft's guidance on safe deployment practices recommends small, incremental, quality-checked changes, standard and consistent deployment patterns, and halting a change and starting recovery as soon as a problem is detected. For a business, that translates into a short routine. Describe the change in writing. Test it on sample data. Choose a quiet time, not month-end. Tell the people affected. Keep the previous version so you can switch back. Check the results the next morning. Record what you did.

Step 8: Retire what is no longer needed

An automation for a retired product or a closed process becomes a risk: it still holds credentials, still touches data and still confuses new staff. Include retirement in the plan, with a date, a final check that nothing depends on it and a note in the inventory. See retired processes leave orphaned automations running for the pattern.

An illustrative example

The following is a hypothetical case. A Johannesburg wholesaler runs eleven automations. In a half-day workshop, the operations manager lists them and finds that three run on a former employee's login and one has not run for a year. Two are tiered critical: the nightly order upload to the courier and the debtors statement run. Each gets an owner, a deputy and a morning summary message with the counts. A monthly slot is placed in the calendar to review failures and expiring credentials. The following month, the courier changes a field name. The order upload fails at 01:00, the summary is missing, and the owner sees it at 07:30. Orders are loaded by hand that morning and the mapping fixed by lunchtime. Before the plan, the same fault would have surfaced in customer complaints three days later.

The point

Automations do not need constant attention, but they do need regular attention. List them, name owners, rank them by consequence, give the critical ones a visible sign of life, decide how failures are handled, review on a calendar and change things carefully. Budget the time each year. The reward is a business that finds problems in the morning rather than from its customers.

Sources and further reading

Retry pattern - Azure Architecture Center (last verified 10 October 2026)
Health Endpoint Monitoring Pattern - Azure Architecture Center
Circuit Breaker Pattern - Azure Architecture Center (last verified 10 October 2026)
Architecture strategies for safe deployment practices - Microsoft Azure Well-Architected Framework