A web application can go live on Monday and begin changing on Tuesday even if nobody on the development team touches the code.
Chrome updates. Safari changes. A JavaScript dependency publishes a security advisory. Traffic grows. The database accumulates another million records. A payment provider changes an API. A TLS certificate moves closer to expiry. The cloud platform releases a new runtime while the version your application uses gets closer to end of support.
Meanwhile, the product itself keeps accumulating data, customers, configuration and integrations.
This is the defining challenge of maintaining a web application after launch: the application lives inside a technical environment that continues moving around it.
Post-launch web application maintenance is therefore not simply fixing defects. It is the ongoing work required to keep the live application reliable, secure, performant, compatible and supportable while browsers, infrastructure, dependencies, data and usage evolve.
For Levelworks, several App Health aspects become particularly relevant here: Current & Updated, Compatible, Secure, Performant, Observable, Error Free and Seamlessly Updatable. The purpose of maintenance is not to change the application continually for its own sake. It is to stop the distance between the application and its operating environment from becoming large enough to create avoidable risk.
A web application does not execute in an environment you control completely. Part of it runs inside the user's browser.
That matters because browser engines continue evolving.
Chrome, Safari, Firefox and Edge add web-platform features, change implementation details, fix defects and occasionally expose assumptions in existing applications. Users also run different browser versions, operating systems, screen sizes and devices.
MDN defines cross-browser testing as ensuring that a web application works across the browsers and devices relevant to its audience, while also noting that supporting every possible browser/device combination is unrealistic. MDN: Introduction to cross-browser testing
That means a web application's browser-support policy should continue after launch.
Useful maintenance work includes:
The Web Platform Baseline project can also help teams understand whether HTML, CSS and JavaScript capabilities have broad browser availability. Baseline currently considers Chrome, Edge, Firefox and Safari across supported desktop and mobile variants, although MDN correctly warns that Baseline does not replace real compatibility, accessibility or usability testing. MDN: Baseline compatibility
The practical objective is not visual perfection in every historical browser.
It is confidence that important user journeys continue working throughout the browser range the business has intentionally agreed to support.
[Internal Link: “Browser Compatibility Testing: How to Keep Web Apps Working Everywhere”]
Modern web applications are assembled from large dependency trees.
The frontend may use a framework, UI libraries, routing packages, authentication SDKs and build tooling. The backend may depend on web frameworks, database drivers, cloud SDKs, logging packages and dozens of transitive libraries.
These components continue changing after your application launches.
OWASP recommends maintaining an inventory of both direct and transitive dependencies, tracking their versions and monitoring them for vulnerabilities and support status. Its current guidance also treats proactive dependency updates as recurring lifecycle work rather than something performed only when a vulnerability becomes urgent. OWASP: Keep Your Components Secure
A sensible web maintenance process therefore includes:
The cadence matters.
Updating a moderately outdated framework can be ordinary maintenance. Updating a framework that has been left untouched for four years can become a migration project involving build tooling, libraries, runtime versions and application code simultaneously.
Regular smaller changes prevent that gap from becoming unnecessarily wide.
[Internal Link: “Why Dependency Updates Are Essential to App Maintenance”]
The application repository is only part of the web stack.
A typical production application may depend on:
Browser
↓
CDN / DNS
↓
Load balancer / proxy
↓
Web server
↓
Application runtime
↓
Application
↓
Database / cache / queues
Security and support problems can emerge in any layer.
OWASP's guidance on vulnerable and outdated components specifically includes operating systems, web/application servers, database systems, runtimes, APIs, frameworks and libraries—not just packages imported directly into application code. OWASP: Vulnerable and Outdated Components
Post-launch maintenance should therefore maintain an inventory of important runtime and infrastructure versions, along with their support lifecycles.
That might include:
A production application can appear completely healthy while the technology underneath it quietly moves toward end of support.
Waiting until support ends turns a planned upgrade into a deadline.
Security testing before launch establishes a point-in-time condition.
It does not preserve that condition indefinitely.
After launch, new vulnerabilities are published, dependencies change, infrastructure is modified and new functionality alters the application's attack surface.
Ongoing web application security attention can include:
OWASP's vulnerability-management guidance explicitly describes vulnerability management as a process that helps maintain application security following changes, bug fixes and ongoing maintenance. OWASP Developer Guide: Vulnerability Management
This does not mean performing a full penetration test after every minor release.
The depth of security work should reflect what changed and what risk it introduced.
A CSS adjustment and a complete authentication redesign clearly deserve different levels of review.
[Internal Link: “Application Security Maintenance: What Needs to Happen After Launch?”]
Web performance is not a property you establish at launch and then keep permanently.
An application changes even without obvious code deterioration because its workload changes.
A dashboard that performs well with 20 customer records may behave differently when an account contains 30,000. A database query can become slower as tables grow. More JavaScript can accumulate through successive feature releases, while new analytics or support scripts increase browser work.
Useful maintenance attention includes:
Do not rely exclusively on averages.
A web application whose median response remains fast may still have a deteriorating p95 or p99 experience that affects a meaningful group of users.
Google SRE's widely used four golden signals—latency, traffic, errors and saturation—remain a useful foundation for understanding live service behavior because they combine user-visible performance with workload and capacity context. Google SRE: Monitoring Distributed Systems
The important maintenance habit is comparison over time.
If a previously stable workflow becomes gradually slower over several releases, that trend deserves investigation before users begin describing the application as “slow.”
Databases often reveal application age more clearly than the code does.
Production data accumulates.
Tables become larger. Queries encounter combinations developers never saw during launch testing. Indexes that were adequate at the beginning may no longer support the workload efficiently.
Post-launch attention should include:
The goal is not constant database tuning.
It is noticing when assumptions about data scale have stopped being true.
Consider a query that scans all historical transactions for a customer. With 300 records, poor query design may be invisible. With 300,000, it becomes a production performance problem.
Web application growth can therefore create maintenance work even where the underlying feature has not changed at all.
Applications often accumulate supporting state outside the primary database.
Examples include:
These components need operating limits and monitoring.
Questions worth revisiting include:
A worker queue that grows slowly for two weeks can leave the user-facing site appearing healthy while background business operations fall progressively behind.
That is why web maintenance needs visibility beyond the HTTP request itself.
A /health endpoint returning HTTP 200 proves very little about whether customers can successfully use the system.
Good production monitoring should cover important workflows and their dependencies.
Depending on architecture, useful signals include:
Google's SRE Workbook describes monitoring as necessary not just for alerting but for diagnosing problems, displaying system state and understanding long-term resource and service-health trends. It also recommends monitoring dependency latency and response behavior rather than treating external calls as invisible implementation details. Google SRE Workbook: Monitoring
That distinction becomes critical in modern web architectures.
If checkout becomes slow because a tax API is taking four seconds to respond, application monitoring should help engineers see that boundary rather than simply report that checkout is slow.
Some of the most disruptive web failures have nothing to do with application code.
A certificate expires.
A domain renewal fails.
A DNS record is changed incorrectly.
An old hostname remains referenced in configuration.
These assets can be quiet for months or years, which makes them easy to forget.
Certificate management increasingly favors automation. Let's Encrypt currently issues its standard certificates with a 90-day lifetime and explicitly cites automation as essential to making short-lived certificates reliable. It has also announced plans to reduce maximum certificate lifetimes further ahead of industry changes later this decade. Let's Encrypt: Certificate Lifetime Rationale and Plans
For production web applications, manually remembering certificate renewal dates is therefore an unnecessary operating risk.
Maintain clear ownership and automated renewal where possible for:
These may seem administrative until one expires.
Then the entire application can become unavailable despite perfectly healthy application code.
Web applications frequently load JavaScript that the application team does not completely control.
Examples include:
These scripts can affect:
A third-party script that becomes slow does not need to take your entire page down, yet poorly isolated dependencies can have exactly that effect.
Maintenance should periodically review which browser-side integrations still exist, whether they remain necessary and whether they continue behaving acceptably.
Remove integrations that are no longer used.
Every script added to the page becomes another piece of production behavior the team may eventually need to investigate.
Web applications can deploy frontend and backend components separately.
That creates periods where users may have an older frontend asset loaded while a new backend version is already live.
Cached browser tabs complicate this further. A customer may keep a page open for hours while server-side behavior changes underneath it.
Maintenance and release design should therefore avoid unnecessary assumptions that every component updates simultaneously.
For example, removing an API response field immediately when deploying a new frontend can break:
Version compatibility and deployment sequencing matter even in applications where frontend releases normally propagate quickly.
The larger subject belongs to backward compatibility, but the operational lesson is straightforward: production web components rarely switch versions at precisely the same instant.
A deployment being technically successful does not prove the application still works.
After meaningful production changes, validate a small number of critical workflows.
Examples might include:
These checks can be automated where practical.
The test should verify useful behavior rather than merely checking that the homepage responds.
For example:
Sign in
↓
Find product
↓
Add to basket
↓
Reach checkout
is a much stronger production signal than:
GET /
→ 200 OK
The maintenance team should know which workflows matter most and verify them after releases.
Configuration problems commonly appear after launch because environments evolve independently.
Examples include:
Where practical, configuration and infrastructure should be version controlled or managed through repeatable automation rather than manually recreated from memory.
Even where sensitive configuration cannot live in source control, its expected existence and ownership should be documented.
A common warning sign is hearing:
“Production has a special setting for that, but I'm not sure where it was changed.”
The longer an application operates, the more dangerous undocumented exceptions become.
Backup processes can report success while still failing to provide usable recovery.
Web maintenance should periodically validate that important application data can actually be restored.
The relevant questions include:
The detailed backup and disaster-recovery strategy belongs elsewhere in the series, but maintenance needs to ensure that existing recovery mechanisms remain usable as the application architecture changes.
A new storage service that never gets added to the backup plan creates an obvious gap.
CI/CD configuration is part of the application operating system.
Over time:
A production application should remain reproducibly deployable.
If the team has not released anything for six months, running the pipeline in a safe environment is often more informative than assuming it still works.
The same principle applies to rollback procedures.
A rollback process that was documented two years ago but has not been tested against the current database and deployment architecture may no longer represent reality.
Different kinds of web maintenance operate on different timelines.
Cadence
Typical attention
Continuous
Errors, latency, availability, queues, critical business flows
After releases
Regression checks, browser errors, performance changes
Regular / monthly
Dependency updates, security findings, storage and database trends
Quarterly / periodic
Browser-support policy, infrastructure versions, unused services
Lifecycle-driven
Runtime, framework, database and third-party platform upgrades
Renewal-driven
Domains, certificates and external credentials
The exact cadence should reflect the application's risk and rate of change.
What matters is that maintenance work becomes routine before any one item turns into an emergency.
The interesting thing about a mature web application is that parts of its original environment gradually disappear.
The browser versions used during launch are replaced. Package versions move on. Infrastructure is upgraded. Databases grow. Certificates renew. External services evolve. New users put the application through workloads the original development team never saw.
The application survives by continuing to move with enough of that environment.
That is the practical relationship between Current & Updated, Compatible, Secure, Performant and Observable App Health. None exists permanently because a release passed QA once.
A well-maintained web application is not frozen in the state in which it launched. It is continually kept close enough to the modern web around it that routine change remains routine.
Once that distance becomes too large, ordinary maintenance starts turning into rescue work.
