In this guide 6 sections
A useful health report maps what runs where, ranks risks by business impact, names every unsupported version and proves that a backup restores onto a clean machine. It lists every login and ends with a plain repair or rebuild call, written for the person paying. Judge it by one test. Can you act on page one?
A map of what runs where
Page one is a map. Read it slowly. It names the web server, the MySQL or PostgreSQL database, the S3 style file storage, the domain registrar and the outgoing SMTP mail sender. Every outside service the code calls follows, such as the payment gateway, the WhatsApp API or the SMS provider that sends one time passwords to customers.
Every line shows who pays and whose account holds it, and many owners learn here that the hosting login belongs to a freelancer who left years ago. That is a risk.
No map, no trust. An auditor who missed a cron job, a staging server or the nightly export script has not audited the whole system, however thick the report looks.
- Hosting provider, server size and region
- Database engine and where the data files sit
- Domain, DNS and certificate renewal dates
- Third party services with their account owners
Risks ranked by what they would cost the business
Forty technical findings help nobody. Ask for risks ranked by business impact, so that an orders table nobody can recover outranks an untidy folder of old scripts.
Each risk states what breaks, who notices first, how long recovery takes and which task you would feel it in, such as invoicing, payroll or dispatch. Labels like high or medium mean little alone.
Good reports also say what is sound. Knowing that the login module and the invoice printing are fine lets you stop worrying about them and spend the effort where it matters.
Unsupported versions and backups that actually restore
Software ages in layers. The report names the PHP, Node or Python version, the framework, the database and the operating system, and flags each one that no longer receives security fixes. End of life Laravel is an open door.
Backups need a harder test than a tick. Ask what is copied, how often, where the copy lives and whether anyone has restored it onto a clean machine, because a backup never restored is only a hope.
Ask when the last restore test ran. No date is the finding. Treat it as a red flag.
- Each component with its version and end of support date
- Backup schedule, location and retention period
- Date and result of the last restore test
- Whether backups sit in a separate account from the server
The access list and the repair or rebuild call
Every person and key that can touch the system gets a line, covering hosting users, database accounts, Git repository members, admin logins and API keys pasted into code. Mark former staff and shared passwords.
Then comes the recommendation. It offers three paths, repair in place, modernise in stages or rebuild, each with its reason, order of work and main risk written in plain words.
Ugly code alone never justifies a rebuild. Look for business reasons instead, such as a dead framework, no tests around the billing rules or a design that cannot take the features you need next.
How to read it and what to do next
Read the summary first. Any term you do not know should be replaced with a plain one, because a report exists for decisions and you should explain it to your accountant.
Check that every finding carries one responsible person plus a rough effort in days, since orphan findings never get fixed and quietly turn into next year’s outage.
Pick the two worst risks. Before the meeting, ask the author what closing both within a month would take, who would do the work and what would stop them.
Health report reading sheet
A single page with six blocks matching the report: system map, ranked risks, versions and end of support dates, backup restore test, access list and recommendation. Each block has three columns, what the report says, what you do not understand and the action, plus who will do it and by when.
Open a blank worksheet to printQuestions owners ask
How long should an application health report be?
Aim for a one or two page summary written for you, followed by technical detail for whoever will do the work, such as the developer or the hosting engineer. Tighten a longer summary.
Does the report fix anything?
No. It describes the state of the software, recommends an order of work and leaves the fixes as separate tasks for the same team or a different one. Fixes are separate work.
Can an audit be done without the original developer?
Usually yes. A reviewer needs read access to the code, the server, the database and the hosting accounts, and nothing else from the original developer. Missing documentation is itself a finding. It does not stop the work.
What if the report says rebuild?
Ask what a staged alternative would look like, which parts of the code can be kept and which modules would be replaced first. Compare the risk of waiting against the cost of change before deciding, and get a second view if the case seems thin.