Imagine a team preparing to release an important update.
The main workflow passes QA, the demo goes smoothly and the application produces the expected result. From a functional point of view, everything works.
Then an engineer raises a concern. The component behind the workflow is difficult to monitor in production, its main dependency is several versions behind, automated coverage around the change is thin and rollback has not been tested for months. None of those problems prevents the feature from working during the demonstration.
They do, however, change what happens if something goes wrong after release.
This is the gap between a working application and a healthy application.
A working app can perform its intended function under the conditions in which you are looking at it. A healthy app can do that while also remaining understandable, secure, recoverable, supportable and safe to change as its environment evolves.
That difference matters because software rarely fails the day it first “works.” Problems appear later, when usage grows, dependencies change, data accumulates, teams release new versions or the people who originally built the system move on.
At Levelworks, this is why App Health goes beyond the simple question:
“Does the app work?”
The more useful question is:
“Is the application in a condition where we can reasonably expect it to keep working?”
[Internal Link: “What Is App Health? 17 Signs of a Healthy Application”]
When someone says an application works, they are usually making a functional claim.
A user can log in. A form submits successfully. An order is processed. The report appears. The API returns the expected response.
Those are essential outcomes. An application that cannot perform its core function is obviously unhealthy.
The problem is that functional success describes what happened under a particular set of conditions.
The login worked for this account, on this browser, against the current identity provider and current version of the application. The report completed using today's database size. The checkout succeeded while the payment service was responding normally.
Production software has to survive a much wider set of conditions.
Google's Site Reliability Engineering guidance reflects this by recommending that teams monitor several different signals—including latency, traffic, errors and saturation—rather than asking only whether a service is technically available. Google SRE: Monitoring Distributed Systems
A request can succeed and still take far too long. The service can remain available while errors increase for one user journey, or infrastructure can operate normally while moving steadily toward a resource limit.
“It works” is therefore a useful observation.
It is not a complete assessment of condition.
One of the easiest ways to see the difference is to imagine that something starts going wrong.
A working application may continue processing requests while one background process fails silently. Customers only discover the problem the following morning when expected data is missing.
A healthier application gives the team evidence earlier: failed jobs are visible, errors have enough context to investigate and meaningful alerts reach someone capable of acting on them.
That distinction is why Levelworks includes both Observable and Explainable & Debuggable in App Health.
The goal is not simply to collect more logs or add more dashboards. It is to make important deterioration visible and understandable.
Without that capability, teams often confuse an absence of reported problems with an absence of problems.
The application may technically work throughout the entire period.
The organisation simply does not know enough about what is happening inside it.
Security shows even more clearly why current functionality is an incomplete measure of health.
Suppose an application passes a security review at launch and continues running without code changes for the next year.
During that year, a vulnerability is discovered in one of its dependencies.
Nothing about the application's functionality has necessarily changed. Pages still load, authentication still completes and users can continue doing exactly what they did before.
Yet the application's health has changed because the risk associated with its software supply chain is different.
The OWASP Top 10:2025 category on Software Supply Chain Failures specifically identifies unsupported, outdated and vulnerable components as risk conditions. It also highlights the importance of tracking component versions and monitoring dependencies rather than assuming software remains safe indefinitely after release.
This is why Secure and Current & Updated matter alongside basic functionality.
A healthy application is not one that was secure once. It is one that can continue responding to new security information as it appears.
That requires something else too: the ability to change the application safely.
Some applications work extremely well until somebody needs to modify them.
A team may have learned that touching one part of the codebase creates unpredictable side effects. Automated tests provide little confidence, deployment contains manual steps and reversing a failed release is possible only if the right engineer happens to be available.
Production can remain stable for months in this state.
In fact, the application may look unusually reliable because teams deliberately avoid making changes.
That stability is fragile.
Applications inevitably need updates. Security problems require patches, integrations change, business requirements move and defects have to be corrected.
AWS's operational guidance explicitly treats the ability to make small, reversible changes, test them and recover quickly from unwanted outcomes as part of operating workloads effectively over time. AWS also recommends designing the workload with deployment and updating in mind rather than treating release mechanics as something separate from software quality. AWS Well-Architected: Operational Excellence
At Levelworks, this is where Tested, Version Controlled and Seamlessly Updatable become health characteristics.
They answer a question that “does it work?” cannot:
What happens when we need it to work differently next week?
The ability to change safely is important enough that it can be measured.
DORA's current software-delivery framework looks at both the throughput of change and the instability it creates. Its measures include areas such as change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework. The point is not to reward teams for releasing as frequently as possible; it is to understand whether software can evolve quickly without becoming unstable every time it changes. DORA: Software Delivery Performance Metrics
Imagine two applications that provide the same functionality today.
In the first, an engineer can make a small change, verify it through reliable tests, deploy through a known process and monitor the result.
In the second, the same request requires days of investigation because the code is tightly coupled, test failures cannot be trusted and production behaves differently from the development environment.
Both applications work.
Only one gives the organisation confidence that it can keep changing.
That difference becomes increasingly important as the product matures.
A similar distinction appears with performance.
An application might currently meet every performance expectation while its underlying trend is deteriorating.
Perhaps an API responds in 500 milliseconds today, which is perfectly acceptable for the product. Six months ago, however, it responded in 250 milliseconds, and the slowdown is closely correlated with database growth.
The app works.
It may even feel reasonably fast.
But its direction raises a health question.
Apple's performance guidance describes performance improvement as a continuing cycle of measuring, investigating and addressing behaviour, and its tooling allows teams to examine metrics from applications that are already shipping to users. Apple Developer: Performance and Metrics
This is why Performant and Scalable are not merely pass/fail characteristics.
A healthy application should give teams enough information to see whether normal growth is slowly consuming the headroom that currently makes the product feel fast.
[Internal Link: “How to Measure App Health: The Metrics That Actually Matter”]
External integrations create the same pattern.
An application might successfully send payments, emails or customer information through a third-party API today even though the provider has already announced that the version being used will be retired.
Technically, the integration works.
Operationally, the application now has a future maintenance requirement.
If the team knows about the change, has enough time to migrate and can test the replacement safely, the situation may be well controlled.
If nobody is monitoring provider notices and the integration is only investigated when it stops working, the same technical condition becomes much riskier.
This is what Integrable means from an App Health perspective. It is not enough to connect two systems successfully once; the relationship has to remain supportable while both sides continue changing.
Functionality also tells you little about what happens under abnormal conditions.
Suppose an application depends on an external recommendation engine.
While the recommendation service is available, both a resilient implementation and a fragile implementation produce exactly the same user experience.
You only discover the difference when the service fails.
The resilient application might temporarily omit recommendations while allowing customers to continue browsing and purchasing. The fragile application could allow the same failed call to prevent an entire product page from loading.
Everything “worked” before the dependency failed.
The health difference was already present; normal operation simply did not expose it.
AWS's Well-Architected guidance recommends anticipating failure, testing recovery procedures and designing operational processes around the assumption that failures will eventually occur.
This is what Levelworks captures through Resilient.
The useful question is not whether the application has experienced a failure recently. It is whether its design and operating processes can prevent an individual problem from becoming a much larger one.
Some weaknesses have almost no runtime symptoms.
Imagine an application that has operated reliably for several years, but almost all important knowledge sits with one senior engineer.
That person understands the deployment process, knows why several unusual configurations exist and remembers the undocumented workaround required when a particular integration behaves unexpectedly.
The software may work beautifully.
The organisation supporting it is fragile.
If that engineer leaves, takes extended leave or simply moves onto another project, routine maintenance suddenly becomes much harder.
That is why Levelworks includes Well Documented and Supported as health characteristics rather than considering them administrative extras.
Healthy software should not depend excessively on individual memory.
The question is not only whether the machine can keep operating, but whether the organisation can continue understanding, supporting and changing it.
The distinction becomes clearer when the two ways of thinking are placed side by side:
“Does it work?” asks…
“Is it healthy?” also asks…
Can the workflow complete?
Can we detect when it stops completing reliably?
Does the application respond?
Is performance stable or deteriorating?
Does the integration connect?
Is the integration still supported and resilient to failure?
Is production stable today?
Can we change production safely tomorrow?
Are there any known security incidents?
Are new vulnerabilities being identified and addressed?
Is the system handling current demand?
How much capacity remains as demand grows?
Can the current team operate it?
Could another team understand and support it?
Does a backup exist?
Has recovery actually been demonstrated?
None of these additional questions makes functionality less important.
They make the judgement more complete.
This is what makes the distinction operationally important.
Many unhealthy characteristics have delayed consequences.
An ageing dependency does not fail immediately. Weak documentation causes little trouble while experienced people remain available. Poor test coverage may not matter until a risky change is required, while insufficient capacity can remain invisible until growth reaches the wrong point.
Because the consequences are delayed, organisations can spend years interpreting continued operation as evidence that there is no maintenance problem.
Eventually, several weaknesses can converge.
A security patch requires a framework upgrade, but the framework is several versions behind. The upgrade affects an integration, yet test coverage around that workflow is weak. The engineer who originally built the integration has left, and the documentation no longer reflects production.
What would once have been a routine maintenance task becomes a significant project.
[Internal Link: “What Happens When You Stop Maintaining an App?”]
The application may have been “working” right up until that moment.
Its health had been deteriorating much earlier.
Moving from a working-app mindset to an App Health mindset does not mean every application has to achieve the highest possible standard across every technical dimension.
That would be impractical.
A small internal tool does not require the same resilience architecture as a financial transaction platform. Some technical debt is entirely reasonable, certain dependencies may temporarily remain behind their newest version and not every workflow deserves identical automated coverage.
Health is contextual.
The important distinction is between known, managed compromise and unseen deterioration.
Perhaps an internal application has limited redundancy because the business can tolerate several hours of downtime. That can be a deliberate, healthy trade-off.
An entirely different situation exists when nobody knows whether recovery works because it has never been tested.
The first is a decision.
The second is an assumption.
A team often begins with statements such as:
“We think recovery will work.”
“We haven't had security problems.”
“The application seems fast enough.”
“That integration has always been reliable.”
“We should be able to roll back.”
An App Health approach tries to replace those assumptions with evidence.
Recovery has been tested. Vulnerabilities are actively tracked. Performance trends are measured in production. Integration failures are visible. Releases have a known rollback or recovery path.
That does not eliminate risk.
It makes the risk understandable enough to manage.
AWS calls this operational readiness: assessing the workload, processes, procedures and people required to support a system rather than assuming functional software alone is ready for continued operation. AWS Well-Architected: Operational Readiness
That is very close to the transition from a working application to a healthy one.
Software has to work.
There is no App Health framework sophisticated enough to compensate for an application that cannot perform the task it was built to perform.
But functionality is the minimum condition, not the final assessment.
A healthy application also makes problems visible, keeps security and technology current enough to remain supportable, performs well under real usage, contains failures, integrates reliably with its environment and gives teams a safe way to release the changes it will inevitably need.
It should also remain understandable to the people responsible for it rather than depending on one person's memory.
That broader condition is what determines whether today's working application can continue supporting tomorrow's users and business requirements.
So when a team says:
“The app works.”
The next question should not be whether the project is finished.
It should be:
“What gives us confidence that it will keep working?”
