You would not service a car by choosing one arbitrary date each year and ignoring everything that happens in between. Tire pressure needs attention to a different rhythm from an oil change, while a warning light demands action when it appears rather than at the next scheduled service.
Application maintenance works much the same way.
There is no useful answer such as “maintain your app once a month” or “service it every quarter.” Some aspects of an application need continuous visibility, some should be checked whenever code changes, others benefit from periodic review, and certain issues require attention as soon as a vulnerability, platform change or failure appears.
A well-maintained app therefore runs on several maintenance cadences at once.
For most product teams, a sensible starting model looks like this:
Maintenance rhythm
Typical work
Continuous
Production monitoring, errors, availability, critical workflows
Every release
Regression checks, deployment validation, performance changes
Weekly or biweekly
Bug and incident review, recurring support issues
Monthly
Dependencies, security issues, performance trends
Quarterly
Broader App Health, capacity, compatibility, recovery, documentation
Event-driven
Critical vulnerabilities, API deprecations, OS changes, incidents
These are practical starting points, not industry-mandated frequencies. The right cadence depends on the importance and behaviour of the application.
Once an application is in production, certain signals are too important to wait for a scheduled review.
Availability, errors, response times and resource pressure are examples. If checkout stops working on Tuesday, discovering it during Friday's maintenance meeting is obviously too late.
Google's Site Reliability Engineering guidance highlights latency, traffic, errors and saturation as four particularly useful signals for understanding user-facing systems.
That does not mean somebody needs to stare at a dashboard all day. Monitoring and alerting should make meaningful deterioration visible when it occurs.
For Levelworks, this connects directly to the Observable App Health Aspect. An app can only be maintained effectively if the team knows when its condition begins changing.
[Internal Link: “Application Monitoring: What Should You Monitor in a Production App?”]
Every production release creates a natural maintenance checkpoint.
Before deployment, teams should confirm that important existing workflows still behave correctly and that configuration, integrations and database changes have been accounted for. Afterwards, production signals should be checked for unexpected increases in errors, latency or resource consumption.
Performance deserves particular attention here because regressions often arrive incrementally. Apple's production-performance guidance encourages teams to examine real-world metrics such as launch time, memory use and responsiveness across released versions so regressions can be identified and addressed.
A product that releases several times a week will naturally perform these checks more frequently than one releasing quarterly.
The cadence follows the rate of change.
This is also why Levelworks treats Tested, Version Controlled and Seamlessly Updatable as App Health Aspects. Maintenance should be built into how changes reach production rather than treated as a separate cleanup exercise weeks later.
Not every problem requires immediate action, but maintenance backlogs should not be allowed to disappear from view for months.
A weekly or biweekly review is often enough to identify patterns such as a bug being reported repeatedly, an error returning after several releases or support teams relying on the same workaround.
The important question is not merely how many tickets exist. It is whether apparently separate issues point to the same underlying weakness.
A low-severity bug that appears once may reasonably wait. A low-severity bug appearing hundreds of times across an important workflow may deserve very different treatment.
The exact meeting rhythm matters less than ensuring that recurring operational problems are reviewed regularly rather than becoming accepted behaviour.
Security creates a problem for fixed maintenance calendars because vulnerabilities do not conveniently appear on the first Monday of every month.
A regular dependency and vulnerability review is useful, but critical findings should be handled according to their risk rather than waiting for the next scheduled cycle.
NIST describes enterprise patch management as the process of identifying, prioritising, acquiring, installing and verifying updates, and frames patching as a form of preventive maintenance that reduces the risk of compromises and operational disruption.
OWASP takes the same ongoing view. Its 2025 guidance on software supply-chain failures warns about unsupported and outdated components and specifically recommends an ongoing plan for monitoring, triaging and applying updates throughout the lifetime of an application.
Tools can help make that work event-driven. GitHub's Dependabot, for example, can generate alerts when new vulnerabilities are identified in dependencies rather than requiring teams to discover them during a manual monthly review.
A sensible pattern is therefore:
review the dependency landscape regularly, but respond to significant vulnerabilities when they appear.
Waiting for a monthly maintenance window may be perfectly acceptable for a routine library update and completely inappropriate for a serious vulnerability affecting an exposed production component.
[Internal Link: “Why Security Patching Should Be Part of Every App Maintenance Plan”]
Some forms of deterioration are easier to see when teams step back from day-to-day tickets.
Every few months, it is worth reviewing questions such as whether application performance has changed noticeably, infrastructure capacity is keeping pace with growth, important dependencies remain supported, third-party integrations have announced future changes, documentation still reflects production, and compatibility testing covers the environments users actually depend on.
This does not need to become a large technical audit every quarter.
Think of it as a health review.
The objective is to find risks that are too gradual to trigger an incident: storage growing faster than expected, a framework falling progressively behind, a manual deployment process becoming increasingly dependent on one engineer, or an API version approaching retirement.
Levelworks' 17 App Health Aspects are particularly useful at this level because they prevent the review from collapsing into a single question such as “did we have any outages?”
An application may remain available while becoming less Secure, Performant, Current & Updated, Scalable, Compatible or Well Documented.
[Internal Link: “The App Health Checklist: How Healthy Is Your Application?”]
Backups create another cadence of their own.
The frequency of taking backups should follow the organisation's tolerance for data loss. AWS recommends setting automated backup frequency according to the application's Recovery Point Objective, with more important datasets backed up more frequently where less data loss can be tolerated.
But creating a backup and proving that it can be restored are different things.
AWS also recommends periodically recovering data to verify backup integrity and confirm that recovery can meet the required Recovery Time and Recovery Point Objectives.
How frequently that test should happen depends on the application and how often its architecture changes. A business-critical platform may warrant regular recovery drills, while a lower-risk internal application may reasonably test less often.
The principle is more important than an arbitrary quarterly or annual rule:
a recovery process that has never been exercised should not be treated as proven.
Mobile apps, web applications and integration-heavy systems are particularly affected by external release calendars.
A new operating-system version may require testing. A browser change can expose a compatibility problem, while a third-party provider can announce that an API version will be retired in six months.
These events do not belong neatly inside a monthly maintenance calendar.
The maintenance cycle should follow the external dependency.
If a provider announces a deprecation deadline, the relevant question is not “when is our next scheduled maintenance?” but rather “how much time do we need to understand, implement, test and release the required change before that deadline?”
This is where Compatible, Integrable and Current & Updated become practical App Health concerns rather than abstract qualities.
The maintenance frequency should ultimately be proportional to risk.
Consider three applications:
A small internal reporting tool used by 20 employees may tolerate occasional downtime and have very few integrations. Continuous basic error monitoring combined with release checks and periodic technical reviews may be entirely reasonable.
A growing SaaS platform serving paying customers changes frequently and handles production data every day. Monitoring, release validation and security alerts should operate continuously, while technical-health reviews need to happen regularly enough to keep up with product growth.
A business-critical transactional system may require much stronger monitoring, faster security response, more frequent resilience testing and tighter release controls because the consequences of failure are materially higher.
The deciding factors include:
Maintenance should get more frequent as the consequences of discovering a problem late increase.
An app can be maintained continuously without developers changing it continuously.
This distinction matters.
Monitoring may show that the application is behaving normally. A monthly dependency review may find nothing urgent. A quarterly health review may conclude that capacity and compatibility remain acceptable.
That is still maintenance.
The purpose is not to manufacture technical work simply because the calendar says maintenance is due. It is to inspect the application's condition often enough that meaningful deterioration does not remain invisible.
Conversely, a team that releases fixes every week is not necessarily maintaining the application well if every fix is a reaction to something users already discovered.
The most useful answer is continuously, but at different depths.
Monitor production continuously. Validate the application whenever you release a change. Review defects and recurring issues frequently enough that patterns do not disappear into the backlog. Examine dependencies, security and performance on a regular schedule, while allowing serious vulnerabilities or platform changes to trigger immediate work. Periodically step back and review the broader health of the application, including recovery, capacity, compatibility and maintainability.
The exact intervals should match the application's risk rather than an arbitrary maintenance calendar.
If there is one question worth using to set the cadence, it is this:
How long could this part of the application deteriorate before we would want to know about it?
For an outage, the answer may be seconds.
For a performance trend, it might be weeks.
For architecture or documentation, it could be months.
Good application maintenance sets each rhythm accordingly.
