Break/fix maintenance can work surprisingly well for a while.
The application is relatively small. Production issues are infrequent. When something breaks, a developer investigates it, makes the correction and moves on. There is little reason to create a more elaborate operating model for problems that barely occur.
Then the pattern changes.
A queue has to be cleared manually again. The same authentication failure returns for another customer. Support forwards an issue engineering already fixed twice. A dependency upgrade gets postponed because a production defect is more urgent. Monitoring catches some problems, while others are still discovered through customer complaints.
The team is working constantly, but an uncomfortable pattern has emerged: more of its time is being spent restoring the application than improving the conditions that caused the restoration work in the first place.
That is usually the point where break/fix has stopped being an efficient maintenance model.
A break/fix model is fundamentally reactive. A problem becomes visible, the team restores acceptable behavior, and maintenance attention moves elsewhere. There is nothing inherently wrong with that for occasional, isolated failures.
The model becomes inadequate when incidents, recurring defects, operational tasks and aging technology begin generating enough predictable work that simply responding to each event no longer addresses the underlying maintenance burden.
Google's Site Reliability Engineering guidance makes the distinction useful through its concept of toil: repetitive, predictable operational work such as restarts, upgrades and alert handling can eventually consume a team if it is not measured and reduced. Google SRE: Eliminating Toil
Here are the clearest signs your application maintenance team has reached that point.
The strongest warning sign is recurrence.
A team fixes a failed background process. Several weeks later, it fails again.
Users repeatedly encounter the same synchronization issue. Support has a workaround. Engineering knows how to resolve it quickly.
Each individual incident may now be easy to handle, which can hide the real problem.
The organization has become efficient at treating the symptom.
Atlassian's problem-management guidance draws a useful distinction here: incident management restores normal service, while problem management investigates the underlying cause and tries to prevent recurrence. When incidents become repeated or sufficiently disruptive, simply restoring service is no longer enough. Atlassian: What Is the Aim of Problem Management?
Watch for:
At that point, the maintenance backlog needs root-cause work, not another identical ticket closure.
[Internal Link: “Why the Same Bugs Keep Coming Back and How to Stop Them”]
Some break/fix teams gradually become operations teams without noticing.
Engineers regularly:
None of these tasks may be large enough to justify a project individually.
Together, they can consume substantial engineering capacity.
Google SRE describes toil as work that tends to be manual, repetitive, automatable and capable of growing with a service. Its guidance recommends first identifying and quantifying that work, then looking for ways to eliminate or automate it. Google SRE: Eliminating Toil
A useful diagnostic is to examine how the maintenance team spent its last few weeks.
If a meaningful portion of capacity went into tasks that will almost certainly need doing again, the team has moved beyond occasional break/fix.
The next maintenance question should be:
Why does this task still require a person?
rather than:
Who is available to do it next time?
A customer reporting an unusual edge-case bug is normal.
A customer regularly being the first monitoring system is not.
If the team repeatedly learns about:
through support tickets, the application has developed an observability gap.
DORA's guidance on monitoring and observability emphasizes using application and infrastructure telemetry to understand system state and inform operational decisions. It also highlights recurring out-of-hours alerts as a potential sign that teams are not paying enough attention to leading indicators of failure.
A mature maintenance model should progressively move detection earlier:
Customer reports failure
↓
Support notices failure
↓
Engineering alert notices failure
↓
Leading indicators show degradation
The further down that sequence the team can reliably operate, the less dependent it becomes on users discovering production problems.
For Levelworks, this is where Observable App Health becomes operationally important.
Look at the top of the backlog.
If it contains only:
then the application has no real preventive maintenance capacity.
The team may understand that dependencies need updating, test coverage is weak or deployment automation needs improvement. Those tasks simply never become urgent enough to beat the latest production problem.
That creates a feedback loop.
Preventive work is postponed because reactive work consumes capacity. The postponed work then makes future reactive work more likely.
Microsoft's Operational Excellence guidance recommends continuous improvement alongside incident response, automation, reliable deployment, testing and observability rather than treating operations solely as response to failures. Microsoft Azure Well-Architected: Operational Excellence Checklist
A maintenance model has outgrown break/fix when not-yet-broken work needs an intentional place in the backlog.
[Internal Link: “Preventive App Maintenance: How to Fix Problems Before Users Find Them”]
Break/fix teams naturally prioritize visible failures.
That works poorly for technology lifecycle work because outdated components may continue functioning perfectly until a deadline suddenly matters.
Examples include:
A team may defer each one because production is currently stable.
Eventually, several versions have accumulated and what could have been a routine update becomes a substantial migration.
The warning sign is not simply having outdated technology.
It is repeatedly deferring known maintenance until external deadlines create urgency.
At that point, the application needs a lifecycle view alongside its incident queue.
For Levelworks, this relates directly to Current & Updated App Health: remaining current requires scheduled attention precisely because nothing may appear broken yet.
Workarounds are useful.
They can get users moving again while engineering investigates a more permanent resolution.
The problem begins when workarounds become the permanent operating model.
You may hear:
“If the import stalls, run it again.”
“If customers see that error, ask them to reconnect their account.”
“Support knows how to reset it.”
That knowledge can make the application appear healthier than it is because support is absorbing defects before engineering sees their full impact.
A useful maintenance review should therefore examine not only engineering bugs but also repeated support procedures.
Ask:
A break/fix model resolves the individual request.
A more mature model notices when the support organization has effectively become a manual compatibility layer around the application.
Fast recovery is valuable.
But imagine a team that has become excellent at resolving the same outage.
Monitoring detects it quickly. The on-call engineer knows exactly what command to run. Service returns within minutes.
Operationally, the response looks strong.
Architecturally, the same weakness remains.
AWS's Operational Excellence guidance recommends performing root-cause analysis after operational events and then either preventing recurrence or documenting an appropriate workaround. AWS Well-Architected: Responding to Events
Google's incident-management guidance makes the same argument: incidents should produce learning that improves detection, mitigation, coordination or the system itself, because recurring outages otherwise increase operational toil. Google SRE: Incident Management Guide
A useful signal to track is therefore:
How many significant incidents create completed improvement work afterward?
If post-incident actions continually disappear behind the next incident, the team is still operating break/fix—even if its emergency response is excellent.
Sometimes the maintenance burden is being produced by the change process.
A release goes out.
Something breaks.
A hotfix follows.
Then another release corrects something the hotfix affected.
If this becomes normal, the team is spending increasing amounts of maintenance capacity repairing its own delivery process.
DORA's current software-delivery metrics explicitly track this type of instability through change fail rate and deployment rework rate—the proportion of deployments requiring immediate remediation and the amount of unplanned deployment work caused by production problems. DORA: Software Delivery Performance Metrics
You do not need to adopt every DORA metric to recognize the signal.
Measure how often production releases require:
If that proportion is increasing, simply staffing more break/fix capacity treats the consequence rather than the delivery problem.
The maintenance response may need better automated testing, safer release practices or narrower changes.
High utilization can look productive.
It can also reveal that the team has no room to reduce future workload.
Suppose engineers close many tickets every month, yet:
The team is processing maintenance work without improving the application's maintenance position.
This is one of the clearest signs that the issue is structural rather than individual performance.
Google's SRE model deliberately places an upper bound on operational work so teams retain engineering capacity to automate, improve systems and eliminate recurring toil. Google's specific 50% limit is part of its own SRE operating model and should not simply be copied into another organization, but the underlying principle is useful: operations cannot be allowed to consume all engineering capacity indefinitely. Google SRE: Eliminating Toil
A maintenance team needs room to make tomorrow's queue smaller.
Break/fix often begins informally.
A problem occurs, and the engineer who knows the application fixes it.
That works until the application and team grow.
Then the same people become permanent escalation points:
“Ask Neha about billing.”
“Only Mark knows how that service restarts.”
“Call the original developer if that integration fails.”
The immediate risk is key-person dependency.
The less obvious cost is interruption: experienced engineers continually stop planned work to supply knowledge that should have been made reusable.
A maturing maintenance model should turn repeated operational knowledge into:
Microsoft's Operational Excellence guidance recommends standardizing routine and emergency operations through documented, repeatable practices and automation. Microsoft Azure Well-Architected: Operational Excellence Checklist
If the same expert has to explain the same recovery process repeatedly, the process is not mature enough yet.
Ticket throughput tells you how much work passed through the team.
It does not tell you whether the application is becoming easier to maintain.
A break/fix organization naturally gravitates toward metrics such as:
Those measures are useful for operational flow.
They should be supplemented with indicators that reveal whether underlying maintenance demand is improving.
Examples include:
Signal
What it reveals
Repeat incident rate
Whether problems are genuinely being eliminated
Manual operational effort
How much capacity recurring tasks consume
User-reported vs internally detected failures
Strength of observability
Change fail / rework rate
Whether releases generate maintenance
Dependency age
Whether lifecycle work is being deferred
Recurring support workarounds
Hidden product/engineering problems
Preventive backlog completed
Whether future risk is actually being reduced
AWS's Well-Architected Framework similarly recommends measuring both workload health and the effectiveness of the operational activities supporting it, then using those measurements to identify areas for improvement. AWS Well-Architected: Operate
The aim is not more dashboards.
It is changing the question from:
How fast are we fixing problems?
to:
Are we creating fewer preventable problems?
Outgrowing break/fix does not mean eliminating reactive maintenance.
Production systems will always produce unexpected problems.
The change is that reactive work becomes one lane of maintenance, not the entire operating model.
A more mature structure typically includes:
Reactive work
Restore service and resolve genuine production defects.
Recurring-problem work
Investigate repeated incidents and eliminate root causes.
Preventive work
Address weaknesses before they create customer-visible failures.
Lifecycle work
Keep frameworks, dependencies, platforms and integrations within manageable support ranges.
Operational improvement
Automate repetitive work, improve monitoring, testing and release safety.
These activities do not need equal capacity every month.
They do need somewhere to exist.
[Internal Link: “How to Prioritize Bugs, User Issues and Feature Requests”]
A break/fix queue is naturally biased toward what failed most recently.
That makes less visible deterioration easy to miss.
Looking periodically across Levelworks' App Health aspects can expose that imbalance.
For example:
This does not require converting App Health into another ticket queue.
It provides a wider view of whether maintenance effort is protecting the condition of the application rather than responding only to visible breakage.
A break/fix team asks whether the service has been restored.
A maintenance team that has moved beyond break/fix asks what should change because the failure happened.
Sometimes the answer genuinely is nothing. Hardware fails, vendors experience outages and unusual edge cases occur.
But when the answer repeatedly involves the same queue, the same workaround, the same manual recovery or the same unsupported component, restoring service should be the beginning of the maintenance decision—not the end of it.
The transition does not require a dramatic reorganization.
It starts when the team deliberately reserves enough attention to remove recurring work, keep technology current, improve detection and make releases safer.
At that point, maintenance stops being defined only by how quickly the team can repair the application after something goes wrong.
It begins to be defined by how much less often the application needs rescuing in the first place.
