Hesklo
Home/Features/SSH checks
SSH checks

Look inside the machine, safely.

A port being open does not mean a server is healthy. An SSH check connects to the host and runs one of a fixed set of read-only diagnostics, so you find a full disk or a stopped service before it turns into an outage.

  • Pick the check, do not type it. You choose a diagnostic from a list rather than writing a shell command, so there is nothing to inject and nothing to typo.
  • Read-only by design. Every available check inspects state. None of them modify the host, so a monitor can never change the thing it is watching.
  • Catch problems before they page you. A disk at ninety percent is a warning. A disk at one hundred percent is an outage. This is the check that finds the first one.
01 · The diagnostics

Four things worth knowing about a server.

Each SSH monitor runs one diagnostic against one host. Add more monitors for more coverage on the same machine.

Service is active

Confirm a named service is running. The check that tells you a daemon died quietly at three in the morning.

Disk usage

Watch a filesystem against a threshold you set. Almost every avoidable outage starts with a disk nobody was watching.

Memory usage

Track how much memory is in use, so a leak shows up as a trend rather than as a machine that suddenly stops responding.

Load average

Know when a host is working harder than it should be, before the queue turns into timeouts.

Your own thresholds

Usage checks compare against a limit you choose, so a build server and a database can be judged differently.

One host, many monitors

Run disk, memory and service checks side by side on the same machine, each with its own interval and its own policy.

02 · Access and safety

A monitor should not be a way in.

SSH access to your servers is the most sensitive thing a monitoring tool can hold. The design keeps it as narrow as possible.

No free-text commands

The check is chosen from a fixed list. There is no field where an arbitrary command could be entered, by you or by anyone who gained access to your account.

Read-only operations

Every available diagnostic inspects state. None of them write, restart or reconfigure anything.

Least privilege

The account you give Hesklo only needs to run these read-only checks. It does not need root and it does not need write access.

Pair with an action step

If you do want automated remediation, put it in an HTTP action step in the policy, where it is explicit and separate from the check itself.

Questions

Common questions

Can I run my own custom command over SSH?
No. You pick from a fixed set of read-only diagnostics: service is active, disk usage, memory usage or load average. This is deliberate. There is no free-text command field, which means there is nothing to inject and no way for a compromised account to turn a monitor into remote code execution on your servers.
What permissions does the SSH account need?
Only enough to run the read-only checks you have configured. It does not need root and it does not need write access anywhere. Giving it the narrowest account that can answer those questions is the recommended setup.
Do I need to install an agent on the server?
No. The check connects over standard SSH, so there is no agent to deploy, keep updated or account for when you rebuild a host.
Can Hesklo restart a service that has stopped?
Not through the SSH check itself, which is read-only. If you want automated remediation, add an HTTP action step to the escalation policy that calls an endpoint you control. That keeps the action explicit and separate from the monitoring.
How is this different from a TCP check on port 22?
A TCP check on port 22 tells you SSH is accepting connections. An SSH check logs in and inspects the state of the machine, so it can tell you the disk is nearly full while the host is otherwise perfectly reachable.
Keep reading

Related features

Find the full disk before your users do.

Three monitors are free forever. Add an SSH check and draw what happens when a threshold is crossed.