A maintenance team can have a very productive month and still end it with a less healthy application.
Every urgent ticket was closed. Production incidents were resolved. Customers received answers. Yet a framework upgrade was postponed again, the same background job required another manual restart, test coverage around a fragile module remained weak, and nobody investigated why users keep discovering failures before monitoring does.
Measured by completed tickets, the team did well.
Measured by the condition of the application, very little improved.
That is the limitation of a pure break/fix maintenance model. It organizes work around visible failure: something breaks, somebody reports it, the team restores normal operation, and attention moves to the next problem.
Break/fix will always have a place in application maintenance because unexpected problems are unavoidable. The problem begins when it becomes the entire maintenance strategy.
A better model is Continuous App Health: continuously understanding the condition of the application, identifying deterioration before it becomes urgent, directing maintenance toward the areas creating the most risk or friction, and verifying that the work actually improved the system.
For Levelworks, this is the difference between maintaining a queue of problems and maintaining the application itself.
Break/fix answers an important question:
What needs fixing right now?
It is much weaker at answering:
What is gradually becoming harder, riskier or more expensive to operate?
Those problems often remain invisible because nothing has failed yet.
A dependency moves several versions behind.
A release process accumulates manual steps.
A database query gets slower as data grows.
An integration approaches deprecation.
Support develops a workaround for a recurring defect.
A critical module becomes increasingly difficult to test.
None necessarily creates an incident today.
Together, they can determine how many incidents the team deals with six months from now.
Google's Site Reliability Engineering guidance describes a related problem through toil: repetitive, predictable operational work such as alert handling, restarts and upgrades can consume increasing amounts of engineering time without creating enduring improvements. Google recommends identifying and measuring that work so teams can engineer it out rather than repeatedly performing it. Google SRE: Eliminating Toil
Break/fix handles the task.
Continuous App Health asks why the task keeps existing.
[Internal Link: “Signs Your App Maintenance Team Has Outgrown a Break/Fix Model”]
“Continuous” does not mean engineers inspect every part of the application every day.
Nor does it mean constantly rewriting software that is functioning perfectly well.
Continuous App Health is an operating cycle:
Observe application condition
↓
Identify deterioration or risk
↓
Prioritize the most important intervention
↓
Make the change safely
↓
Verify the outcome
↓
Continue observing
The important change is that maintenance becomes condition-driven, not purely incident-driven.
An application might have no critical incidents this month and still need maintenance because:
Conversely, an old application may require relatively little intervention if its important health indicators remain stable and it continues meeting business needs.
Continuous App Health therefore does not manufacture maintenance work.
It provides evidence for deciding where maintenance is actually worthwhile.
Before improving App Health continuously, you need a baseline.
That baseline should identify which parts of the application's current condition matter most.
Levelworks' App Health framework looks across 17 aspects:
Observable, Secure, Resilient, Error Free, Performant, Current & Updated, User Friendly & Delightful, Supported, Scalable, Integrable, Explainable & Debuggable, Tested, Version Controlled, Seamlessly Updatable, Well Documented, Compatible and Compliant.
Not every application has equal risk in every aspect.
A customer-facing SaaS platform may need particularly strong Observable, Scalable and Integrable health.
A regulated financial application may place greater weight on Secure, Resilient and Compliant.
A mature internal application may be operationally stable but suffer mainly from poor Well Documented or Current & Updated health.
The baseline exists to expose that difference.
It should answer:
That gives maintenance a starting point other than whichever ticket arrived most recently.
A Continuous App Health model needs evidence from the application itself.
Ticket volume is not enough.
Closing twenty performance complaints does not tell you whether performance improved. Closing five recurring bugs does not reveal whether the underlying defect was removed.
DORA's guidance on monitoring and observability recommends visibility into both overall system health and the state customers actually experience, along with the ability to diagnose unexpected production behavior.
Useful App Health evidence may therefore include:
The exact measures should reflect the application.
A payments system and a content-management platform do not need identical health dashboards.
The principle is to measure the condition you want maintenance to protect.
[Internal Link: “How to Measure App Health: The Metrics That Actually Matter”]
Continuous maintenance becomes difficult when the team cannot see deterioration.
AWS's Well-Architected guidance describes observability as using metrics, logs and traces to understand workload behavior, establish baselines and detect deviations that require action. It specifically connects observability with proactive improvement rather than merely responding after failure. AWS: Implement Observability
That does not mean building an enormous observability platform before maintenance can improve.
Start with the blind spots that matter.
If customers regularly discover failed background jobs first, monitor those jobs.
If an important integration has historically failed silently, measure its business outcome.
If slow performance drives support complaints, establish a production performance baseline.
Every useful signal should make a maintenance decision easier.
Collecting thousands of metrics that nobody acts upon does not create healthier software.
Monitoring becomes valuable when it changes the backlog.
Suppose production evidence shows:
Report-generation p95 latency has increased steadily over several months.
The maintenance response is not necessarily “add more servers.”
The team investigates.
Perhaps one query is deteriorating as customer data grows. That becomes targeted maintenance work.
Or suppose support records show that users repeatedly encounter the same synchronization problem.
Instead of processing each occurrence independently, the recurring pattern becomes engineering work aimed at removing the cause.
This creates a feedback loop:
Production evidence
↓
Maintenance priority
↓
Engineering change
↓
Production evidence
DORA describes monitoring as a mechanism for feeding operational learning back into development and product decision-making rather than keeping production knowledge isolated in operations. DORA: Monitoring Systems to Inform Business Decisions
That feedback loop is central to Continuous App Health.
Reactive work is naturally good at getting attention.
There is already a failure, a customer or an escalation.
Preventive work has weaker immediate pressure.
That is why it needs deliberate capacity.
Examples might include:
The goal is not to create a separate backlog filled with vaguely beneficial technical work.
Preventive tasks should have an observable reason.
For example:
Update Framework X
is weaker than:
Framework X reaches end of support this year; update now while the version gap remains manageable.
Likewise:
Improve monitoring
is weaker than:
Three recent payment-sync failures were discovered by customers because the application has no alert on synchronization delay.
Evidence makes preventive maintenance easier to prioritize against visible defects.
[Internal Link: “Preventive App Maintenance: How to Fix Problems Before Users Find Them”]
Incidents will continue happening under a Continuous App Health model.
The difference is what happens afterward.
Google's incident-management guidance recommends learning from outages so similar failures can be prevented or their impact reduced. It warns that recurring incidents otherwise accumulate operational toil and continue affecting users. Google SRE: Incident Management Guide
After a meaningful incident, ask more than:
Is production restored?
Ask:
The answer might create a code fix.
It might instead produce a new alert, automated recovery, stronger test, updated runbook or architectural improvement.
Not every production bug needs a formal postmortem.
Repeated or high-impact failures should leave the application better prepared than they found it.
Some forms of deterioration barely appear in production telemetry.
A framework can run perfectly well while approaching end of support.
An API can remain functional while its provider announces retirement.
A certificate can work flawlessly until the day it expires.
Continuous App Health therefore needs a lifecycle view alongside production monitoring.
Track important:
Then make expected lifecycle work visible before it turns into emergency maintenance.
This is particularly important for Current & Updated, Compatible, Secure and Integrable App Health.
A healthy application is not one where every component runs the newest available version.
It is one where technology age remains understood and manageable.
Imagine a worker process that periodically stops and requires an engineer to restart it.
A break/fix model might document the restart process and make sure support can perform it quickly.
That improves recovery.
Continuous App Health goes one step further:
Why does the worker need restarting at all?
Google SRE recommends measuring toil and, where worthwhile, eliminating it at the source through engineering rather than repeatedly managing it. Google SRE: Eliminating Toil
Look for maintenance activity with three characteristics:
Those are strong candidates for automation or root-cause work.
The result is not only lower operational effort.
It releases maintenance capacity for work that improves application condition.
Continuous App Health depends on being able to correct deterioration without creating disproportionate release risk.
If every maintenance change requires a large manual test cycle and a stressful deployment, teams will naturally postpone preventive work.
That makes Tested and Seamlessly Updatable App Health important enablers of the entire model.
DORA describes continuous delivery as keeping software in a deployable state throughout its lifecycle, supported by practices including testing, monitoring, security and deployment automation. DORA: Continuous Delivery
For maintenance teams, the practical goal is not necessarily releasing constantly.
It is maintaining the ability to make small, controlled changes when they are needed.
That shortens the distance between identifying a health problem and correcting it.
Urgent tickets will always dominate a meeting if they are allowed to.
Give broader application condition its own review.
For many teams, a monthly or quarterly App Health review is more useful than attempting to discuss everything every week.
Review changes such as:
AWS's Operational Excellence guidance recommends continuously evaluating workload health, identifying opportunities for improvement and using operational evidence to guide action. AWS: Operational Excellence
The review should produce decisions, not merely a status report.
If an App Health concern appears quarter after quarter with no change in priority or accepted risk, the process is not helping.
Continuous App Health should eventually change the type of work the team performs.
Useful indicators include:
Signal
What improvement might look like
Repeated incidents
Same failure occurs less often
User-discovered failures
More important failures are detected internally
Operational toil
Less recurring manual intervention
Dependency risk
Fewer components drift far beyond supported versions
Release instability
Fewer changes require rollback or emergency correction
Recovery effort
Important incidents become easier to diagnose and restore
Preventive work
More identified risks are addressed before failure
App Health risks
High-priority weaknesses reduce over time
Do not expect every metric to move continually in the right direction.
Applications change. Usage grows. New features create new risks.
The important question is whether maintenance is controlling deterioration faster than the application creates it.
A company does not need a sophisticated reliability organization before it can adopt this model.
A practical transition can begin with four changes.
First, establish a baseline of the application's most important health risks.
Second, improve visibility where significant problems are currently discovered too late.
Third, reserve some maintenance capacity for recurring, preventive and lifecycle work instead of allowing urgent tickets to consume everything.
Fourth, review whether completed maintenance is improving the application's condition.
The first version will be imperfect.
That is fine.
Continuous App Health is itself iterative.
The important shift is that maintenance starts asking not only what needs attention today, but what condition the application is moving toward.
Break/fix is good at restoring yesterday's condition.
If a service fails, fix it. If a bug appears, correct it. If a customer cannot proceed, help them.
None of that disappears.
The difference is that a mature maintenance model does not stop there.
Repeated failures should become less repetitive. Manual recovery should become less manual. Technology should not become outdated unnoticed. Monitoring should improve when blind spots are discovered. Tests and release processes should make future changes easier rather than more frightening.
That is the idea behind Levelworks' Continuous App Health approach.
The 17 App Health aspects provide a broader view of application condition than an incident queue can provide, while continuous maintenance turns that view into practical engineering priorities.
The result is not an application that never develops problems.
It is an application where deterioration becomes visible early enough to manage, maintenance effort increasingly produces durable improvement, and the team spends less of its time repeatedly repairing problems it already knows how to prevent.
