A Formula 1 car can still be moving at 300 km/h while something is beginning to go wrong.
The driver may not feel it yet, but the engineers watching telemetry can see tyre degradation, abnormal temperatures, declining performance or another signal that says the car will not stay competitive for long if nothing changes. Judging its condition only by asking “Is it still moving?” would miss almost everything that matters.
Applications are much the same.
An app can be online and serving users while errors quietly increase, response times drift upwards, dependencies approach end-of-support or releases become increasingly risky because only one person understands how part of the system works.
None of those problems necessarily takes the application offline today, yet each says something important about whether it can continue operating well tomorrow.
That is what App Health is designed to capture.
At Levelworks, we define a healthy application through 17 characteristics:
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.
Together, these provide a much more useful picture than uptime, bug counts or any other single metric.
App Health is the overall condition of an application: how reliably, securely and effectively it works today, how easily problems can be understood and corrected, and how well the application can continue adapting as technology, users and business requirements change.
There is no universal metric that can answer all of that. Google's Site Reliability Engineering guidance, for example, looks at multiple production signals including latency, traffic, errors and saturation rather than relying on one indicator. Google SRE: Monitoring Distributed Systems Apple's production tooling measures a different set of characteristics, including responsiveness, launch performance, memory use and application termination. Apple: Performance and Metrics Security introduces another perspective altogether: the OWASP Top 10 covers risks spanning access control, configuration, software supply chains, authentication and security logging. OWASP Top 10:2025
A healthy application is therefore not an application with one impressive metric. Its different dimensions of health need to work together.
Levelworks' App Health framework looks at these 17 characteristics:
A healthy app is…
What that means
1. Observable
Its health and behaviour can be monitored so problems become visible early.
2. Secure
Systems and data are protected against threats and unauthorised access.
3. Resilient
It remains reliable under pressure and can recover from failures.
4. Error Free
Errors affecting normal use are identified, understood and resolved.
5. Performant
It delivers fast, responsive experiences under real usage conditions.
6. Current & Updated
Its technology and functionality are kept relevant and supportable.
7. User Friendly & Delightful
People can use it intuitively and effectively.
8. Supported
Issues receive ongoing attention rather than being left unresolved.
9. Scalable
Growth can be accommodated without unacceptable loss of stability or performance.
10. Integrable
It can interact reliably with the external systems it depends on.
11. Explainable & Debuggable
Its behaviour can be understood and problems can be traced efficiently.
12. Tested
Important functionality is validated so changes do not repeatedly introduce defects.
13. Version Controlled
Changes to code and configuration are traceable and safely managed.
14. Seamlessly Updatable
Improvements can be released without unnecessary disruption.
15. Well Documented
Important knowledge about the application is recorded and accessible.
16. Compatible
It continues working across the environments it is intended to support.
17. Compliant
It meets the legal, security and industry requirements relevant to it.
A healthy application does not need to be perfect across all 17. What matters is that weaknesses are known, controlled and improving, rather than accumulating invisibly.
[Internal Link: “The App Health Checklist: How Healthy Is Your Application?”]
You cannot confidently say an application is healthy if you cannot see how it is behaving.
Observability means being able to understand that behaviour through the information the application produces: logs, errors, metrics, traces and other operational signals.
A basic uptime check might confirm that the server responds. Good observability should tell you much more: whether checkout is failing, whether an API has become slower since the last release, whether error rates are climbing for one workflow or whether a background process has stopped completing successfully.
Google SRE's widely used “four golden signals”—latency, traffic, errors and saturation—illustrate why this broader view matters. Google SRE: The Four Golden Signals Infrastructure can look healthy while the experience users depend on is already deteriorating.
A healthy application therefore makes meaningful deterioration visible early enough for somebody to respond, rather than relying on customers to become the monitoring system.
[Internal Link: “Application Monitoring: What Should You Monitor in a Production App?”]
Security health is not simply the absence of a known breach.
A secure application protects its systems, users and data while continuing to respond to new risks as they emerge. That can include authentication, authorisation, data protection, secure configuration, dependency management and vulnerability response.
The ongoing element matters because an application can become less secure even when its own code has not changed. Vulnerabilities are continually discovered in frameworks, packages and infrastructure components.
The current OWASP Top 10:2025 includes risks related to broken access control, security misconfiguration, authentication failures, software supply-chain failures and failures in security logging and alerting.
Security therefore has to be treated as a living property of the application.
A healthy app knows what it depends on, understands material vulnerabilities and has a dependable way of addressing them.
Failures are unavoidable in any sufficiently important application. Networks become unreliable, external services experience outages, infrastructure develops problems and unexpected traffic arrives.
Resilience is about limiting what happens next.
If an ecommerce site relies on an external recommendation provider and that service becomes temporarily unavailable, the healthier outcome may be to remove recommendations while leaving browsing and checkout unaffected. Allowing the failed recommendation call to bring down the entire product creates a much larger problem from the same initial failure.
Recovery is part of resilience too. Teams should know how the application returns to normal operation after a failure rather than inventing that procedure during an incident.
AWS recommends designing workloads so component failures are detected and contained, with recovery or failover mechanisms appropriate to the application's availability requirements. AWS Well-Architected: Design Workloads to Withstand Component Failures
A resilient application is not one that never encounters problems. It is one designed to prevent those problems from spreading unnecessarily.
No meaningful application can realistically guarantee that an error will never occur.
For Levelworks' App Health framework, Error Free is more practical than that: errors affecting normal use should be kept to a minimum, detected when they occur and resolved rather than slowly becoming accepted behaviour.
Recurring errors are particularly informative because they usually point to something underneath the individual incident. A workflow may be fragile, validation may be inadequate, an external dependency may be unreliable or a recent change may have introduced a regression.
A healthy application therefore does more than count errors. It gives the team enough information to understand what failed, where it happened, who or what was affected and whether the behaviour is becoming more frequent.
The warning sign is not simply that an error exists. It is that the same problem can keep affecting users without being properly understood or corrected.
Users experience performance directly, whether they describe it technically or simply say that the application “feels slow.”
Loading time, interaction responsiveness, API latency, memory use and other relevant measures depend on the type of application, but the underlying requirement is the same: the software should respond quickly enough for the experience it is intended to provide.
For web applications, Google's Core Web Vitals provide one useful view of real-world loading performance, responsiveness and visual stability.
Native applications require different measures. Apple, for example, provides production metrics covering areas including launch time, memory use and responsiveness, and recommends comparing performance across shipping versions to identify regressions. Apple: Analyzing the Performance of Your Shipping App
The important word is across.
An application being fast after an optimisation exercise does not mean it will remain fast as features, data, scripts and integrations accumulate. A healthy application makes performance drift visible.
Applications live inside a technology ecosystem that continues to change.
Frameworks release new versions, APIs are retired, libraries become unsupported and operating systems introduce new requirements. The application's own business requirements can change as well.
Being Current & Updated does not mean adopting every new technology or immediately installing every new version. That can create unnecessary risk of its own.
It means keeping the application's technology and relevant functionality sufficiently current that the product remains secure, supportable and reasonably easy to maintain.
A workflow that matched users' needs three years ago may also need refinement as the product matures. Health therefore requires selective evolution rather than change for change's sake.
The danger appears when updates are postponed for so long that the distance between the application and its surrounding ecosystem becomes difficult to close safely.
Technical health ultimately exists to support users.
An application can have excellent infrastructure, clean code and reliable deployments while still being frustrating to use. Navigation may be confusing, common actions may require unnecessary effort or error states may leave users with no clear way to recover.
A healthy application should therefore be usable and pleasant enough that the technology does not create unnecessary friction around the task the user is trying to complete.
User Friendly & Delightful does not mean adding animation or visual polish for its own sake. It means the interface, information architecture and interactions help people accomplish what they came to do.
This dimension also has to be revisited over time. Real usage can reveal friction that was difficult to predict during design, while adding new features can gradually make once-simple workflows harder to understand.
Applications need ownership after launch.
When that ownership is unclear, known defects remain open, users develop workarounds and important maintenance tasks are easily deferred because everyone assumes somebody else is responsible.
A Supported application has a dependable way of responding when something goes wrong or needs attention. The exact operating model can vary enormously: a small internal tool does not need the same support organisation as a customer-facing financial platform.
What matters is clarity around responsibility.
Who receives an important alert? Who investigates a production problem, coordinates a fix and makes sure unresolved issues do not simply disappear into a backlog?
At Levelworks, support is part of App Health because even well-built software can deteriorate when nobody is clearly responsible for its continued condition.
Scalability means an application can accommodate the growth it reasonably needs to support without unacceptable deterioration in performance or stability.
Growth does not only mean more users. It can mean larger datasets, more transactions, additional integrations, heavier background processing or expansion into new regions.
Google SRE describes saturation as how close a service is to the limit of an important resource. Google SRE: Monitoring Distributed Systems A system operating close to its limits may appear perfectly healthy during ordinary conditions while having little room for growth or temporary spikes.
Healthy scalability therefore starts with understanding where constraints exist and how much headroom remains.
An application does not need unlimited capacity. It needs enough capacity that normal business growth does not automatically become a production incident.
Modern applications rarely operate alone.
Payments, authentication, customer data, notifications, analytics, maps, storage and AI capabilities may all depend on external systems. From the user's perspective, however, these integrations are simply part of the product.
A healthy application needs to interact with them reliably.
That means integrations cannot be treated as something implemented once and forgotten. Providers change API versions, authentication requirements, limits and supported functionality over time.
Integrability therefore includes both the application's ability to connect with external systems and its ability to maintain those connections as each side evolves.
It also requires understanding what happens when a dependency is unavailable. If an external service fails, does the application degrade sensibly or does an unrelated part of the product stop working too?
When something goes wrong, how difficult is it to find out why?
That question reveals a great deal about application health.
A debuggable application produces enough useful information for engineers to investigate behaviour without relying mainly on guesswork. Logs have context, errors can be connected to relevant requests or workflows and important events leave enough evidence to reconstruct what happened.
This overlaps with observability, but the two are not identical.
Observability helps you see that something is happening. Explainability and debuggability help you understand why.
Without that ability, even relatively simple production issues can turn into lengthy investigations because engineers know the symptom without understanding which component, request or dependency produced it.
As applications become more complex, avoiding this “black box” condition becomes increasingly important.
Testing gives teams confidence that the application continues behaving as intended.
That includes validating individual functionality as well as protecting important user journeys from regression when something changes.
The appropriate balance between automated and manual testing will differ by product. What matters for App Health is that critical behaviour can be verified consistently rather than relying entirely on somebody remembering what to test after every release.
Without enough testing, changes become unnecessarily uncertain. A defect is corrected in one place but another workflow breaks, or a dependency upgrade alters behaviour that nobody realised depended on it.
Healthy testing reduces that uncertainty and makes maintenance safer.
The absence of known bugs is useful; the ability to stop yesterday's bug from quietly returning six months later is healthier.
Healthy applications need traceable change.
Version control records how code and related configuration evolve, making it possible to understand what changed and to return to a known previous state when necessary.
This is fundamental to maintainability because production software should not depend on undocumented modifications whose history nobody can reconstruct.
A Version Controlled application allows teams to compare changes, review them, understand which version is running and investigate whether a particular release introduced a problem.
Within Levelworks' framework, this aspect connects closely to configuration management and release safety.
Changes should be deliberate and traceable rather than depending on somebody's memory of what was modified directly in an environment months earlier.
Applications inevitably need to change, whether because of security patches, feature improvements, dependency updates, integration changes or new business requirements.
The health question is how safely those changes can reach users.
A Seamlessly Updatable application has a release process that makes ordinary changes predictable rather than disruptive. Depending on the application, that can include automated validation, consistent environments, staged deployment and the ability to reverse a problematic release.
AWS recommends keeping changes small and reversible because smaller changes reduce the scope of potential failure and are generally easier to troubleshoot and recover from. AWS Well-Architected Framework
This is an important App Health signal because an application can appear completely stable while carrying significant hidden risk if the team is afraid to deploy anything to it.
A system that stays reliable only as long as nobody changes it is not sustainably healthy.
Software knowledge disappears surprisingly quickly.
Developers leave, architectural decisions lose their original context and an integration implemented several years ago can continue operating long after anyone remembers why it was built in a particular way.
Documentation protects the application against that loss of knowledge.
Being Well Documented does not mean every line of code needs an accompanying explanation. It means information that matters to the application's operation and maintenance is recorded somewhere people can actually find it.
That may include architecture, important dependencies, deployment procedures, configuration, APIs, recovery instructions and operational processes.
A useful test is to ask:
If the people currently maintaining the application changed, how much essential knowledge would disappear with them?
If the answer is “most of it,” the application has a health problem even if production is currently running perfectly.
The environment surrounding an application keeps changing as browsers, operating systems, devices and infrastructure platforms evolve.
Healthy compatibility means the application continues working across the environments the organisation has committed to supporting.
That does not mean supporting everything indefinitely.
The important thing is to define the support boundary and keep testing against it. A company that supports particular browser or operating-system versions should know whether important functionality still behaves correctly there.
Compatibility problems are especially easy to overlook because they can appear even when the application's own code has not changed. Something outside the product moves, and functionality that worked yesterday begins behaving differently.
Maintaining compatibility keeps the app aligned with its actual operating environment rather than the environment in which it originally launched.
Applications may need to operate within legal, regulatory, security or industry-specific requirements.
Exactly what applies depends on the application, the organisation operating it, the data it processes and the jurisdictions or industries involved.
A healthy application understands those obligations and maintains the relevant technical controls.
Compliance should not be confused with security. They overlap considerably, but security asks whether systems and data are appropriately protected, while compliance asks whether the organisation and application satisfy the requirements that apply to them.
Those requirements can change, as can the way an application processes data or supports business operations.
For applications subject to meaningful regulatory or contractual obligations, compliance therefore cannot always be treated as a box checked once during development.
The most useful way to think about App Health is not as 17 isolated scores.
The dimensions affect one another.
Poor observability makes errors harder to detect, which makes debugging slower and weakens support. An outdated framework may simultaneously affect Current & Updated, Secure, Compatible and Integrable. Weak testing can make ordinary updates risky enough that the application becomes progressively harder to keep current.
This interconnectedness is important because real application problems rarely stay neatly inside one category.
A recurring production failure, for example, may initially appear to be an Error Free problem. Investigation could reveal that poor logs make it difficult to diagnose, weak test coverage allows the issue to return and a fragile release process makes teams reluctant to deploy the deeper fix.
The ticket is the symptom. App Health provides the context around it.
[Internal Link: “How the Different Dimensions of App Health Work Together”]
The existence of 17 dimensions should not turn App Health into a pursuit of technical perfection.
Every real application contains trade-offs. Technical debt exists, some dependencies will occasionally lag behind the newest release and certain workflows will receive stronger automated test coverage than others.
Context matters as well. An internal application used by 20 employees does not require the same resilience architecture or operational processes as a payment system handling business-critical transactions.
The useful questions are not whether every dimension is perfect
