Web Application Maintenance Checklist: What a Good Plan Actually Covers

A web application is not finished when it launches. It sits on a framework, a hosting platform, dozens or hundreds of third-party packages and a handful of external services, and every one of them changes. Maintenance is the work of keeping all that moving in step so the application stays safe, available and fit for purpose. It is rarely noticed when done well, and expensive when it is not.

This is general guidance written for owners of business-critical web applications. It is not a substitute for a security assessment of your own system.

The six jobs of maintenance

1. 01SafeUpdates and access controls close known gaps.
2. 02AvailableMonitoring and hosting keep it running.
3. 03RecoverableBackups restore when something fails.
4. 04CorrectTests catch breakage before customers do.
5. 05FastPerformance is checked, not assumed.
6. 06UnderstoodSomeone can explain how it works.

The checklist

Use this as a starting point and adapt it. For each control, the "evidence" column is what you should be able to ask for and see.

Maintenance controls, frequency and evidence

Control	Typical frequency	Evidence to expect	Owner
Framework and dependency security updates	As releases appear; review weekly	A log of versions and dates applied, plus a note when an update is deliberately deferred	Developer
Operating system, runtime and container base image updates	Monthly at least, sooner for security fixes	Current version list and last patch date	Developer or host
Backups	Daily for data that changes daily	Backup log showing successes and failures	Developer or host
Restore test	At least quarterly	A dated note of a successful restore to a test environment	Developer
Uptime and error monitoring	Continuous	Alert rules naming who is contacted, with out-of-hours cover agreed	Developer
Domain, DNS and certificate expiry	Calendar reminders well ahead	A list of expiry dates and the account that holds each	Owner
Access review	Quarterly and on every leaver	A list of accounts with role, last login and multi-factor status	Owner and developer
Secrets and keys rotation	On a schedule and after any exposure	Rotation log, with no keys in code or screenshots	Developer
Automated tests on key journeys	On every change	Passing test run linked to each release	Developer
Performance review	Quarterly	Core Web Vitals or equivalent against an agreed budget	Developer
Third-party service changes	Monthly check of notices	A list of integrations with deprecation or pricing notices tracked	Developer
Documentation and runbook	Updated when anything changes	How to deploy, roll back, restore and who to call	Developer

Patching: how fast is fast enough?

The question owners most often ask is how quickly updates need to go on. The NCSC has a direct answer. Its guidance says to adopt a policy of updating by default, applying software updates as soon as possible and ideally automatically. It lists best-practice timescales that apply to all updates regardless of severity: 5 days for internet-facing services and software, 7 days for operating systems and applications, and 14 days for internal or air-gapped services. It adds that for business-critical systems you should balance these timescales against availability.

Cyber Essentials, the UK government-backed scheme, sets a minimum rather than a best practice. Version 3.3 of its requirements says software in scope must be licensed and supported, and that updates fixing critical or high-risk vulnerabilities must be applied within 14 days of release. If you hold, or plan to obtain, a certificate, ask your assessor whether your web application's components fall inside the scope you have declared.

A real example of the cadence

The pace of releases is not theoretical. If your application uses Next.js, the project published security fixes on 21 July 2026 (four high-severity and five moderate advisories) and on 30 September 2026 (seven advisories), and on 8 October 2026 it announced another out-of-band security update for 14 October 2026. That is two releases and one announced update inside roughly twelve weeks. A plan that says "we update once a year" does not fit that rhythm. Our Next.js 16 upgrade checklist walks through staying current on that framework in particular.

The same applies to every other dependency, so the useful question for any supplier is not "do you patch?" but "within how many days, and how will I know?"

Backups are only a hypothesis until you restore

A backup that has never been restored is a hope rather than a control. Ask for two things: a log showing backups running, and a record of the last time someone restored one into a test environment and checked the data was usable. Also ask where the backups live, because a backup stored in the same account as the system it protects is vulnerable to the same mistake or attack.

Monitoring that reaches a person

Monitoring only helps if the alert reaches someone who can act. Check three things:

1. What is monitored: availability, error rates, slow responses, failed jobs, certificate expiry.
2. Who receives the alert, and what happens at night, at weekends and when that person is on holiday.
3. What the first response is. A short runbook beats improvisation at two in the morning.

Access: the quiet risk

Most maintenance failures that become incidents involve access: a former contractor who can still log in, a shared password, a service key in a code repository. Keep a list of every account with access to hosting, the domain registrar, the code repository, the database and third-party services. Remove people when they leave, require multi-factor authentication, and give each person only what their role needs.

Tests: the thing that makes updates safe

Updating a dependency is risky only if you cannot tell whether something broke. A small set of automated tests on the journeys that matter, such as logging in, submitting an enquiry and paying, turns patching from a gamble into a routine. If your application has none, building them is often the best first investment. Our software testing and QA automation service is aimed at exactly this gap.

Performance is part of maintenance

Applications slow down gradually: a new tracking script, a larger image, a heavier dependency. Review speed against an agreed budget each quarter, as we describe in Next.js performance budgets that teams actually keep. Slowness is a customer-experience issue before it becomes an engineering one.

Questions to ask a developer or agency

1. Who is named as responsible for security updates, and what is the target time to apply them?
2. When did you last restore a backup, and can I see the record?
3. Who gets alerted when the site is down, and when are they available?
4. Which accounts have access to my hosting, domain and code, and who holds the master credentials?
5. What tests run before each release?
6. What is covered by the monthly fee and what is billed separately?
7. If you stopped working with us tomorrow, what would I need to take over, and how long would it take?

Warning signs include a single person holding every credential, "unlimited changes" with no testing, no documented restore, and answers that depend on someone's memory.

Taking over an unmaintained application

If you have inherited an application nobody has looked after, resist the urge to start with new features. A sensible first month looks like this:

1. Establish control. Confirm ownership of the domain, hosting, repository and database, and list every account.
2. Make a backup and test a restore. Do it before touching anything else.
3. Find out what is running. Record framework, runtime and dependency versions and which are unsupported.
4. Close the highest risks. Apply the security updates that matter most, in a branch, with tests around the critical journeys.
5. Add monitoring and write the runbook.

If the application is too far behind to patch sensibly, that is a different conversation, which we cover in modernising a legacy web application without a rewrite.

What maintenance costs

We are not going to quote prices, because they depend on how complex the application is, how critical it is and how much cover you need. The honest levers are: how many systems are involved, how quickly you need responses, whether out-of-hours cover is required and how much automated testing already exists. Be wary of any quote that cannot tell you what is included.

How SystemNexa can help

Our managed web application services cover patching, monitoring, backups and small improvements for applications we have built and for applications we inherit. Related work includes web application development and website performance optimisation.

Conclusion

Maintenance is a set of boring, repeatable controls with named owners, and the best sign you have a good plan is that each control produces a piece of evidence. Ask for the evidence, check the dates and make sure at least two people know where everything is. If you would like a view of the state of your own application, talk to us about managed web application services.