What each method tells you
| Question | Uptime monitoring | Server monitoring |
|---|---|---|
| Can users reach the service? | HTTP, DNS, TLS and TCP checks provide an outside view. | A healthy agent does not prove a public website works. |
| Why is it failing? | Status codes, timeouts and response times narrow the failure. | CPU, memory, disk and processes provide machine-level context. |
| What can it miss? | A basic HTTP check can pass while an application returns an error page. | Normal resources can coexist with DNS, certificate or application failures. |
Follow one outage through both views
Consider a server whose disk fills while the application is writing data. An external check may observe HTTP 502 responses. Disk metrics may show the filesystem reaching capacity before the first failed request. A process list can help identify a busy service, but does not establish why the disk filled. These observations support an investigation; they do not prove causation by themselves.
Check the affected mount, logs and recent changes before deleting anything. After recovery, keep a disk-usage alert below the failure point and confirm external checks recover too. This is a worked scenario, not a customer incident.
What should you install first?
Start with an external check for the service users depend on. Add a server agent if you operate the machine. For a hosted application where you cannot install an agent, external checks still provide useful availability information.
Statance combines external uptime checks with agent-reported server metrics. Pro and Business add full security monitoring and automatic AI incident investigation. Compare current plans before choosing check frequency, regions and retention.
Set up uptime monitoring and install the Linux agent. For applications that fail with a successful HTTP status, use content or JSON assertions.