A great football team is not simply eleven individually talented players.
A world-class striker can score goals, but their effectiveness depends on the midfield creating chances. The midfield depends on defenders recovering possession, while the defence becomes easier to organise when the team presses well further up the pitch. Even the goalkeeper's job changes depending on how effectively everyone in front of them performs.
That is why a weakness in one part of the team rarely stays neatly contained there. A struggling midfield can force defenders into more difficult situations, which puts greater pressure on the goalkeeper and eventually changes how confidently the entire team can attack.
Applications behave in much the same way.
A performance problem may actually begin as a scalability problem. A recurring production error becomes much more expensive when poor observability makes it difficult to diagnose. An ageing framework can create security exposure while simultaneously making compatibility, integrations and future releases harder. Weak testing can make teams reluctant to update the very dependencies that are already becoming outdated.
At Levelworks, we describe App Health through 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.
These are useful individually, but the real value of the framework appears when you stop treating them as 17 separate boxes.
Application health is a system. One dimension can strengthen several others, while a weakness in the wrong place can gradually pull the rest of the application down with it.
Understanding those relationships is what turns App Health from a checklist into a useful way of reasoning about an application.
[Internal Link: “What Is App Health? 17 Signs of a Healthy Application”]
The relationships between different dimensions usually show up in one of three forms.
Good observability makes debugging easier. Strong testing makes deployments safer. Good documentation improves supportability. Keeping technology current can make security and compatibility easier to maintain.
Improving one dimension can therefore produce benefits well beyond the original problem.
The opposite happens too.
An outdated dependency may begin as a Current & Updated concern but later become a Secure issue when a vulnerability is discovered, a Compatible issue when the surrounding platform moves on, and a Seamlessly Updatable issue when the eventual upgrade becomes difficult.
The original weakness has not merely become more severe. It has spread.
This is more subtle.
A highly capable operations team can repeatedly recover from a fragile application, making its poor resilience less visible. Excellent infrastructure capacity can conceal inefficient software for years. One experienced developer can compensate for weak documentation because they remember exactly how the system works.
The application appears healthier than it is because people or technology around the weakness are absorbing its consequences.
That compensation usually lasts until circumstances change.
This is why App Health cannot be understood by evaluating each dimension in isolation.
Start with Observable and Explainable & Debuggable.
These two dimensions do not guarantee that an application will be secure, performant or resilient. What they do is make weaknesses in those areas easier to discover and understand.
Google's Site Reliability Engineering guidance makes a useful distinction between symptoms and causes. Monitoring might show that users are receiving errors or requests are becoming slow; further diagnostic information is then required to determine whether the underlying cause is an overloaded database, a failing dependency or something introduced in a recent release. Google SRE: Monitoring Distributed Systems
That distinction maps naturally onto App Health.
Observable answers:
What is happening?
Explainable & Debuggable helps answer:
Why is it happening?
Consider an API whose error rate begins rising after a deployment.
If the application is observable, the team sees the increase quickly. If logs and traces contain useful context, engineers may connect those failures to a particular database interaction or external service.
Now compare the same technical defect in an application with poor visibility.
The error still exists, but nobody notices until customers complain. Engineers then spend hours reproducing the problem because production logs contain little useful information.
The underlying bug is identical.
The operational impact is completely different because other App Health dimensions changed the team's ability to respond.
This is why weak observability often makes an application look more Error Free than it really is. The errors have not disappeared; the organisation is simply less capable of seeing them.
Performance problems are another good example of health dimensions interacting.
Suppose an application becomes slower as usage grows.
The visible problem is Performant: users are waiting longer.
But perhaps the real cause is that the database is approaching a connection limit or a worker queue can no longer process requests at the rate they arrive. That makes the problem partly Scalable.
If the overloaded component then fails completely and brings several unrelated workflows down with it, Resilient has entered the picture too.
One production symptom can therefore expose weaknesses across three health dimensions.
Google SRE describes saturation as how close a system is to an important resource limit and notes that latency often starts increasing before a service reaches complete utilisation. A performance trend can therefore act as an early warning that scalability is weakening.
Architecture determines how far the problem spreads.
AWS's reliability guidance recommends using fault isolation so that failure in one part of a workload remains within a defined boundary rather than affecting the entire system. AWS Well-Architected: Fault Isolation
AWS makes a similar point about loosely coupled dependencies: reducing coupling can isolate the behaviour or failure of one component while also making individual components easier to scale or change. AWS Well-Architected: Implement Loosely Coupled Dependencies
That is the interaction between Performant, Scalable, Integrable and Resilient in practice.
An application should not merely handle today's workload quickly. Its architecture should prevent normal growth or one struggling dependency from turning a local weakness into a system-wide failure.
Integrable is particularly interesting because it exposes the application to someone else's App Health.
A payment provider, authentication system, mapping service or messaging platform can experience latency or failure even when every component you own is operating perfectly.
The health question therefore becomes:
What does your application do when the system it depends on becomes unhealthy?
AWS recommends monitoring the response times and error rates of important dependencies, setting appropriate timeouts and considering how communication failures or latency will affect the workload. AWS Well-Architected: Identify Distributed-System Dependencies
Imagine that an ecommerce application calls an external recommendation API while constructing its product page.
If the integration is designed so that recommendations can fail independently, the user might see the product without the recommendation section. Integrable has weakened temporarily, but Resilient contains the damage and the core experience remains User Friendly & Delightful enough to continue.
If the entire page waits indefinitely for the same API, one external dependency can simultaneously damage performance, resilience and user experience.
The dependency did not change.
The way the application's health dimensions interact determined the outcome.
Security can easily be discussed as if it were an isolated discipline: scan the system, find vulnerabilities and fix them.
In reality, an application's ability to remain Secure depends heavily on several other health dimensions.
The OWASP Top 10:2025 category on Software Supply Chain Failures identifies outdated, unsupported and vulnerable software components among its important risk conditions. OWASP also recommends an ongoing process for monitoring and applying updates throughout the lifetime of an application.
Now imagine a critical library needs updating.
Whether the security issue can be resolved efficiently depends on more than the security team's recommendation.
If the application is Current & Updated, the version gap may be small.
If it is well Tested, engineers can identify regressions introduced by the change.
If the code and configuration are Version Controlled, the update is traceable.
If deployment is Seamlessly Updatable, the patch can reach production without extraordinary disruption.
If the system is well Observable, the team can detect unexpected behaviour after release.
Security therefore relies on a chain of other healthy capabilities.
The reverse is equally important. An application can have excellent vulnerability detection while remaining insecure because the software is too difficult to change safely.
NIST's Secure Software Development Framework recommends practices designed not only to reduce vulnerabilities in released software but also to address their root causes and reduce future recurrence.
That is fundamentally a systems view of health: fixing today's vulnerability is useful, but improving the way the application is developed, tested and maintained makes future security easier too.
Applications have to change if they are going to remain healthy.
Security fixes need releasing, integrations need updating, performance problems need correcting and business requirements evolve.
Three Levelworks App Health Aspects play a particularly important role in determining how safely that can happen:
Tested
Version Controlled
Seamlessly Updatable
These dimensions reinforce one another.
Version control provides traceability around change. Testing supplies evidence that the proposed change has not broken important behaviour. The deployment process then moves the validated change into production in a controlled way.
Remove one part and the rest becomes less valuable.
Excellent automated tests provide limited protection if engineers make undocumented changes directly in production.
A sophisticated CI/CD system cannot make weakly tested code safe merely by deploying it efficiently.
Version control records exactly what changed, but that history does little to protect users if there is no reliable process for validating or rolling back a release.
AWS groups many of these capabilities together in its operational guidance: version control, testing, configuration management, build and deployment systems and small reversible changes are treated as complementary ways to reduce defects and make remediation easier. AWS Well-Architected: Design for Operations
The interaction matters because improving this cluster can influence other areas of App Health.
A safer change process makes teams more willing to upgrade dependencies, which helps Current & Updated and Secure. It becomes easier to correct performance issues, repair integrations and make compatibility changes.
In other words, changeability acts as an enabler for health elsewhere.
The opposite pattern is common in ageing applications.
Imagine the tests are unreliable, deployment requires manual steps and engineers are uncertain whether the repository completely represents production.
A framework update becomes available.
The team delays it because the release feels risky.
Several months later, another update arrives and is also postponed. Eventually, the framework is several versions behind and one of its dependencies develops a security issue.
The original weakness was not simply “old technology.”
The sequence might have been:
Weak Tested → difficult releases → updates postponed → Current & Updated declines → security exposure grows → eventual upgrade becomes larger and riskier.
At that point, several App Health dimensions are reinforcing deterioration rather than reinforcing health.
This is one of the reasons technical weaknesses often compound.
Improving testing may appear to address only Tested, but in the right application it can also make Secure, Current & Updated, Compatible and Seamlessly Updatable easier to maintain.
DORA's software delivery research captures part of this relationship by considering delivery throughput and instability together. Its current model examines measures including deployment frequency, lead time, failed deployment recovery time, change fail rate and deployment rework rather than assuming that software delivery can be judged through speed alone. DORA: Software Delivery Performance Metrics
The broader lesson applies to App Health: healthy change requires both the ability to move and the ability to do so without repeatedly damaging the system.
Not every relationship between App Health dimensions is encoded in software.
Some depend on organisational knowledge.
Consider a production issue that only one senior developer knows how to diagnose. The application may technically be Explainable & Debuggable to that individual, but weak Well Documented and Supported health makes the organisation dependent on that person's availability.
If they leave, the condition of the source code has not changed.
The application's practical maintainability has.
Documentation, support ownership and debuggability therefore work together.
Useful documentation shortens the distance between noticing a problem and understanding the system involved. Clear support ownership ensures the problem reaches someone capable of acting on it, while good diagnostic information helps that person resolve the issue efficiently.
This combination matters especially during incidents, handovers and unfamiliar maintenance work.
A technically sophisticated application that can only be operated by its original developers is healthier on paper than it is in reality.
Some App Health dimensions are driven heavily by things outside the application.
A browser releases a new version. An operating system changes behaviour. A provider deprecates an API. A framework ends support for an old runtime.
These external changes can affect Compatible, Integrable and Current & Updated simultaneously.
Suppose a mobile operating system introduces a platform change that affects an old SDK used by the application.
If the SDK is current, the vendor may already provide support.
If the application has fallen several versions behind, updating it might first require framework changes. Those framework changes may affect other dependencies and require broader regression testing.
Again, a compatibility problem that looks isolated has exposed the accumulated condition of several other areas.
A healthy application does not have to adopt every external change immediately, but it should remain close enough to its environment that normal evolution can be absorbed without turning every update into a rescue project.
User Friendly & Delightful may look like a predominantly design-oriented dimension.
In practice, users experience the combined output of many App Health dimensions.
A slow application is a poor user experience even if the interface itself is well designed.
A checkout that fails because a payment integration is unreliable is a UX problem from the customer's perspective, regardless of which backend service caused it.
An application that loses user input during a failure may technically recover while still producing a frustrating experience.
Security can influence user experience too. Excessively restrictive authentication introduced without considering usability can create unnecessary friction, while weak security creates a different form of user harm.
This is one reason App Health should not be divided too rigidly into “technical” and “user” concerns.
Users experience the application as one product.
They do not care that the error they encountered belongs to Integrable while the delay belongs to Performant and the unclear recovery message belongs to User Friendly & Delightful.
The framework is useful for diagnosis.
The user's experience is where those dimensions recombine.
So far, many examples have involved deterioration. The same relationships can create a healthier upward cycle.
Consider this sequence:
Better Observability identifies recurring production errors earlier.
Improved Explainable & Debuggable makes their causes easier to understand.
The team adds regression coverage, strengthening Tested.
A controlled release fixes the problem, supported by Version Controlled and Seamlessly Updatable practices.
Monitoring confirms the fix and reveals whether performance changed.
Documentation records anything operationally significant, strengthening Well Documented and future Supported work.
One improvement becomes input to the next.
This is what a healthy maintenance system should do.
The dimensions stop behaving like separate technical responsibilities and instead create a feedback loop:
Observe → understand → change → test → release → verify → learn.
That loop also explains why some investments have disproportionate value.
Improving observability does not merely improve dashboards. It can reduce debugging time, expose performance deterioration, reveal integration failures and give teams better evidence after deployments.
Better testing does not merely increase coverage. It can make security updates, compatibility changes and refactoring safer.
Good documentation does not merely satisfy a process requirement. It can improve support, onboarding, incident response and future maintenance.
The best App Health improvements often strengthen several parts of the system at once.
Working together does not mean every health dimension can simply be maximised independently.
There are trade-offs.
Stronger security controls can introduce user friction if implemented poorly.
Adding redundancy can improve resilience while increasing infrastructure complexity and operational cost.
Supporting a very wide range of browsers or operating systems improves compatibility for some users but increases testing and maintenance effort.
Heavy instrumentation can improve observability while adding some runtime overhead and generating additional data to manage.
Aggressive performance optimisation can produce complex code that becomes harder to debug or maintain.
These tensions are not evidence that the framework is inconsistent.
They are the reason health has to be considered as a system.
A good App Health decision asks whether improving one dimension creates disproportionate harm elsewhere.
For example, reducing API latency from 180 ms to 160 ms may provide little meaningful value if the optimisation makes the code significantly harder to understand. Similarly, maintaining compatibility with a browser used by almost nobody may no longer justify the testing and security limitations it imposes.
Healthy applications involve deliberate trade-offs, not maximum scores everywhere.
It is tempting to treat App Health as a weakest-link problem.
Sometimes that is useful. One severe security weakness can matter enormously even when everything else looks healthy.
But many application-health problems are better understood as combinations.
Moderately weak observability might be manageable in a simple application. Combine it with weak debuggability and poor documentation, and incident diagnosis can become extremely difficult.
Some technical debt may be acceptable. Combine outdated technology with poor test coverage and a fragile deployment process, and that debt becomes much harder to correct.
A moderately stressed database may be manageable. Combine it with rapid customer growth and tightly coupled services, and the same constraint can become a resilience risk.
The interaction changes the severity.
This is why health assessments should look for clusters of weakness rather than merely ranking the 17 dimensions independently.
[Internal Link: “The App Health Checklist: How Healthy Is Your Application?”]
One of the easiest ways to make these interactions concrete is to stop assessing “the application” in the abstract and follow an important user journey.
Take an ecommerce checkout.
Start with the user pressing Pay.
Can the team observe whether the request succeeds? That involves Observable.
Can engineers determine why a failed request occurred? Explainable & Debuggable.
Is payment information protected appropriately? Secure and potentially Compliant.
Does the payment provider integration behave reliably? Integrable.
If that provider becomes slow, does the application time out sensibly rather than hanging indefinitely? Resilient and Performant.
Can the checkout handle peak demand? Scalable.
Does the interface explain a failed payment clearly enough for the user to recover? User Friendly & Delightful.
Are important checkout scenarios protected against regression? Tested.
If the payment provider introduces a required API change, can engineers update the integration through a traceable, controlled release? Current & Updated, Version Controlled and Seamlessly Updatable.
If the engineers who built the integration leave, can another team understand how it operates? Well Documented and Supported.
Suddenly the 17 dimensions no longer look like an arbitrary list.
They describe different conditions that have to cooperate for one important workflow to remain dependable.
The same exercise can be repeated for login, report generation, file upload, order processing or whatever function actually matters to your application.
This is another reason the relationships matter.
Imagine users report that a screen is slow.
The immediate temptation is to label it a Performant problem.
Investigation might reveal that an external API is timing out repeatedly, making it primarily an Integrable issue.
Or perhaps usage has doubled and the application has reached a database constraint, making Scalable the deeper concern.
Maybe the slowdown began after a deployment and insufficient performance testing allowed the regression into production, connecting the incident to Tested.
The symptom and the health weakness are not always the same thing.
Google SRE's distinction between symptoms and causes is useful here because treating symptoms alone can lead teams toward repeated fixes that never improve the underlying condition.
App Health gives teams a vocabulary for following those relationships instead of stopping at the first visible problem.
A useful assessment should ask more than “How strong are we in each of the 17 dimensions?”
Add questions about the connections.
If observability deteriorated tomorrow, which other areas would become harder to manage?
If testing weakened, which future upgrades would become riskier?
Poor compatibility, an ageing framework and difficult security patching may all trace back to the same deferred modernization problem.
Treating them as three separate maintenance tickets can miss the opportunity for one intervention to improve all three.
Is one engineer making poor documentation appear harmless?
Is large infrastructure headroom hiding inefficient code?
Is an unusually capable support team absorbing defects that should be corrected?
Compensation matters because it can create hidden dependencies.
If a particular external service fails, what else stops?
If one database becomes saturated, how many user workflows are affected?
The answer reveals whether Resilient, Integrable, Performant and Scalable are working together appropriately.
Sometimes the highest-leverage maintenance task is not the most visible defect.
Improving deployment safety, observability or test reliability can make several other health problems easier to address afterwards.
App Health metrics still matter, but they should be interpreted together.
An increasing error rate means something different when latency and saturation are rising at the same time.
A high change failure rate becomes more concerning when recovery is also slow.
A growing dependency backlog matters more when several packages are unsupported and the test suite provides little confidence around upgrades.
This is why a single App Health score can be misleading.
If you average every dimension together, a serious weakness can disappear inside otherwise healthy numbers. More importantly, a score rarely shows how weaknesses interact.
At Levelworks, the better question is not simply:
Which dimensions are red?
It is:
Which combination of conditions is making the application harder to operate, change or trust?
[Internal Link: “How to Measure App Health: The Metrics That Actually Matter”]
No real application is equally strong across all 17 dimensions.
There will be compromises, ageing components, areas with weaker testing and technical decisions that made sense for an earlier stage of the product.
The difference between a manageable weakness and an unhealthy application often lies in the surrounding system.
An ageing dependency is less dangerous when it is known, monitored, well tested and easy to update.
A production incident is less damaging when it is detected quickly, diagnosable and recoverable.
A performance constraint is less concerning when capacity trends are understood and the architecture can scale before the constraint becomes critical.
A key developer leaving is less disruptive when knowledge has been documented and ownership is shared.
Health therefore comes partly from the strength of individual dimensions, but equally from the way those dimensions support one another.
That is the larger idea behind Levelworks' App Health framework.
An application is not healthy because Observable gets a green tick, Secure gets another and Performant gets a third.
It is healthy when those capabilities combine into something greater: a system whose problems can be seen, understood and corrected; whose technology can evolve without unnecessary disruption; and whose weaknesses are prevented from quietly spreading into every other part of the product.
Just like the football team, the goal is not to assemble 17 individually impressive capabilities.
It is to make sure they work together.
