A doctor would never declare someone healthy simply because their heart is beating.
That is a necessary sign of life, but it says very little on its own. Blood pressure, symptoms, medical history and other indicators can reveal problems that a pulse cannot.
Applications have the same problem.
Teams often judge software health using whichever signal is easiest to see: uptime is high, the bug backlog is small, or no major incident has happened recently. Those are useful indicators, but an application can satisfy all three while running on unsupported dependencies, becoming slower with every release, relying on fragile integrations or depending on one engineer who understands how production actually works.
An App Health check asks a broader question:
Is this application in a condition where we can continue relying on it, supporting it and changing it safely?
At Levelworks, we assess that through 17 App Health 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.
This checklist turns those aspects into practical questions your product and engineering teams can answer.
[Internal Link: “What Is App Health? 17 Signs of a Healthy Application”]
This is not intended to generate an arbitrary score out of 100.
A payment platform and an internal HR tool should not be assessed against identical expectations. The impact of downtime, security exposure or slow recovery is completely different.
Instead, classify each area as:
Status
What it means
Healthy
You have evidence the area is working as expected and material risks are controlled.
Needs Attention
The application works, but there is a known weakness, deterioration or uncertainty.
High Risk
There is a material weakness, little evidence of health, or failure could have serious consequences.
The important word is evidence.
“We have backups” is weaker than “we restored a backup and verified the data.”
“Users have not complained about performance” is weaker than production measurements showing important workflows remain within acceptable response times.
The checklist is useful because it exposes where confidence is based on facts and where it is based mainly on assumption.
If something starts going wrong, would your team know before the problem becomes serious?
Check whether:
Google's Site Reliability Engineering guidance identifies latency, traffic, errors and saturation as four particularly useful signals for user-facing systems. Google SRE: Monitoring Distributed Systems
Warning sign: Users or support teams regularly discover production problems before engineering does.
[Internal Link: “Application Monitoring: What Should You Monitor in a Production App?”]
Security health is not the same as “we have never been breached.”
Check whether:
The OWASP Top 10:2025 includes risks involving broken access control, misconfiguration, authentication, software supply chains and security logging. The NIST Secure Software Development Framework likewise treats addressing vulnerabilities in released software as an ongoing responsibility.
Warning sign: Nobody can confidently identify which vulnerable or unsupported components are running in production.
Healthy applications should expect dependencies and infrastructure to fail occasionally.
Check whether:
AWS recommends designing systems to tolerate component failures and testing recovery rather than simply assuming resilience will work as intended. AWS Well-Architected: Reliability
Warning sign: Your recovery plan exists mainly as a document nobody has exercised.
No meaningful application is literally free from every error. The important question is whether recurring user-facing errors are detected and resolved rather than becoming part of normal operation.
Check whether:
Warning sign: Everyone inside the organisation knows which process occasionally needs rerunning, but nobody is fixing why it fails.
Performance should be judged where users experience it.
Check whether:
For web applications, Google's Core Web Vitals provide useful field measures of loading, responsiveness and visual stability.
Warning sign: Slow behaviour is accepted because “it has always been like that.”
Being healthy does not require installing every new version immediately, but the application should not drift so far behind that ordinary updates become risky.
Check whether:
Warning sign: Applying one necessary security patch first requires several framework and runtime upgrades.
Technical quality does not compensate for a confusing product.
Check whether:
Warning sign: Support regularly has to explain how to complete a supposedly self-service workflow.
An application can deteriorate quickly when post-launch ownership is unclear.
Check whether:
Warning sign: When something fails, the first discussion is about who is responsible for it.
Scalability should be assessed against realistic demand rather than theoretical infinite growth.
Check whether:
Google SRE uses saturation to describe how close a service is to an important resource limit. Google SRE: Monitoring Distributed Systems
Warning sign: Every meaningful rise in usage requires an emergency infrastructure change.
Third-party services change independently of your application.
Check whether:
Warning sign: An API retirement becomes visible only when the provider's deadline is close.
Finding an error and understanding it are different capabilities.
Check whether:
Warning sign: Most incident time is spent discovering what happened rather than correcting the cause.
Testing protects the application when something changes.
Check whether:
Warning sign: Release confidence comes mainly from the belief that “the change was small.”
Production software should have a traceable history.
Check whether:
Warning sign: Engineers are unsure whether the repository accurately represents production.
An application may appear healthy until somebody tries to update it.
Check whether:
Warning sign: Important updates are repeatedly delayed because nobody wants to touch production.
Documentation should be judged by whether it helps people operate and change the application.
Check whether useful documentation exists for:
Warning sign: The fastest route to understanding a critical system is still “ask the person who built it.”
Compatibility changes even when your code does not.
Check whether:
Warning sign: Compatibility testing happens only after a customer reports a failure.
Compliance depends heavily on the application's industry, geography, data and contractual obligations, so there is no universal checklist.
At minimum, check whether:
Warning sign: The main evidence that the application remains compliant is that it passed an assessment several years ago.
Once the checklist is complete, resist the temptation to convert it immediately into a percentage.
An application with 15 healthy areas and two serious weaknesses is not automatically “88% healthy.”
If the two weak dimensions are Secure and Resilient in a financial application, their importance may outweigh several perfectly healthy areas.
Look instead for patterns.
If Observable and Explainable & Debuggable are both weak, production problems may be difficult to detect and diagnose.
If Current & Updated, Compatible and Integrable are all deteriorating, the application may be falling behind the technology ecosystem around it.
Weakness across Tested, Version Controlled and Seamlessly Updatable often points to an application that works today but is increasingly dangerous to change.
Similarly, deterioration across Performant and Scalable can indicate that current usage is still acceptable while expected growth is approaching a technical limit.
This is why the 17 App Health Aspects are more useful as a connected diagnostic model than as 17 independent scores.
[Internal Link: “How the Different Dimensions of App Health Work Together”]
One of the most useful outcomes of an App Health check is finding reassuring statements that have never been demonstrated.
“We have backups.”
Can you restore them?
“We can roll back.”
When was the rollback procedure last exercised?
“The application scales.”
To what load has that actually been demonstrated?
“We have monitoring.”
Would it detect failure of the workflow users care about most?
AWS recommends periodically restoring backups specifically because having backup files does not prove that recovery will work when required. AWS Well-Architected: Back Up Data
Apply the same principle throughout the health check: where failure would matter, replace assumed confidence with evidence.
An App Health check should create actions, not just observations.
For each area marked Needs Attention or High Risk, record:
Question
Why it matters
What is the weakness?
Make the problem specific.
What evidence supports it?
Avoid prioritising vague concerns.
What happens if nothing changes?
Connect technical weakness to a realistic consequence.
How urgent is it?
Not every health issue requires immediate work.
Who owns the next step?
Unowned findings rarely improve.
How will we know it is healthier?
Define what evidence would change the assessment.
Context should determine priority.
A dependency being one minor version behind may simply need monitoring, while an unsupported framework carrying a relevant security vulnerability may require immediate action.
App Health is not a certification.
An application can improve or deteriorate after the assessment is complete, sometimes without a major incident.
Comparing health checks over time makes that direction visible. Performance may be improving while dependencies are ageing, releases may be getting safer while documentation is becoming weaker, or several previously high-risk areas may be steadily moving toward healthy.
The trend can tell you more than the snapshot.
[Internal Link: “How to Measure App Health: The Metrics That Actually Matter”]
A useful App Health check should tell you where there is evidence of strength, where confidence is based mainly on assumption, and where one weakness is beginning to affect several other parts of the system.
That is why Levelworks looks across 17 connected App Health Aspects rather than treating uptime, security scans or performance scores as complete answers on their own.
Your application does not need a perfect result.
It needs enough visibility that the team knows where deterioration is occurring, enough context to decide which weaknesses matter, and enough ownership to address the issues that genuinely threaten the product.
The most useful outcome is therefore not:
“Our app is healthy.”
It is:
“We know where our app is healthy, where it is not, and what needs attention next.”
