Features · Outage diagnostics
Outage diagnostics
When a site comes back, the reason it went down is already collected
Most outages leave their evidence in the minutes around recovery — a service that crashed, memory that ran out, a disk that filled. Astrari captures that state automatically as the site recovers and puts a likely cause in front of you, instead of leaving you to reconstruct it from logs the next morning.
What it does
Triggered by the outage itself
Uptime probes run every minute and alert after two failed checks. When a site that was down for five minutes or more recovers, Astrari asks the agent on its server for a forensic diagnostic straight away.
Evidence, not just a status code
The diagnostic records boot time, load and memory, out-of-memory kills, failed services, disk fullness, and recent error lines from the web server, PHP and database logs — filtered to the outage window.
A likely cause, in plain language
Rules read the report and name the probable cause: a crashed web or database service, a server that ran out of memory, a full disk. They tell apart a whole server running out of memory from one service hitting its own memory limit, so you fix the right thing.
Linked from the recovery alert
The resolved outage finding links to the diagnostic, so the recovery email, the dashboard and the monthly report all carry the explanation with them. One outage across many sites on a server produces one diagnostic, not dozens.
What it typically explains
- ▸ A web server, PHP-FPM or database service that crashed or failed to restart
- ▸ A server that ran out of memory, and which process the kernel killed
- ▸ A single service killed at its own memory limit while the rest of the server was fine
- ▸ A disk or filesystem that filled up
- ▸ An unexpected reboot, and when it happened
- ▸ Database errors such as refused connections, crashes or table corruption around the outage
Example diagnosis
Server ran out of memory — php-fpm killed
The kernel's out-of-memory killer stopped php-fpm at 11:52, two minutes before the site stopped responding. Memory was exhausted server-wide, not just within one service.
How it works
- 1
Uptime probe sees the site fail
Probes run every minute from outside the server. Two consecutive failures open an availability finding and alert you.
- 2
The site recovers
When probes succeed again, the outage finding resolves and you get a recovery notice.
- 3
The agent captures the server's state
On its next 30-second check-in the agent collects the diagnostic — it takes a second or two and sends a small report.
- 4
Astrari names the likely cause
The diagnosis appears on the server's page, linked from the resolved outage finding. You can also run a diagnostic yourself at any time.
Plans
Outage diagnostics and on-demand forensic diagnostics are included on every plan. Compare plans.
Good to know
- ▸ Automatic diagnostics need the site linked to a server running the Astrari agent. Agentless sites still get uptime alerts.
- ▸ Outages shorter than five minutes don't trigger a diagnostic, to avoid noise from brief blips.
- ▸ The agent must be online when the site recovers; if not, run the diagnostic from the dashboard.
See it on your own servers
The free Starter plan covers one website and one Linux server. The agent installs with one command and reports its first scan within a minute.