SSH Workbench
Built into SSH Workbench

Server monitoring without agents

Watch your servers, cron jobs, disks, services, backups and SSL certs, all from cron pings your server sends out. No agent to install. No inbound ports to open. Every check is a cron entry you can read.

Start free trial

How it works

Two steps. No SDK, no API integration, no agent.

01

Pick what to watch

Point and click in SSH Workbench, across many servers at once, with defaults you set once.

Server uptimeCron jobsDisk spaceMemoryCPUServicesSSL certificatesBackups
02

Alerts come to you

Your server checks itself on schedule and pings out. When a ping is late or a check fails, you get an email. A test-alert button lets you confirm delivery first.

Nothing listens on your server and nothing connects in. Every check lives in one cron file per server that you can read, edit or delete.

How checks get set up, and where pings land

What works today, and what is on the way.

Setting up checks

SSH Workbench
Point and click, across your whole fleet. Part of your license.
ssw CLI (coming soon)
A free, open-source ssw CLI is on the way.

Where pings land

Our receiver
The default. Nothing to run and nothing to maintain, with email alerts already wired up.
Your own receiver (coming soon)
Self-hosting a receiver, so every ping stays on your infrastructure, is coming soon.

Four subscriptions, or one agent you did not want

This is what people usually stitch together to cover the same ground.

Cron and heartbeats
  • Cronitor
  • Healthchecks
Uptime and alerting
  • Better Stack
  • UptimeRobot
Metrics and logs
  • Datadog
  • Netdata
SSH Workbench

All of it from cron entries your server already knows how to run. No daemon and no inbound port.

No agent. No daemon. No inbound port.

Most monitoring tools install a binary that runs as root and phones home with a black-box payload. Ours writes one cron file per server that you can read, edit or delete.

Here is what a service check looks like once it is on the server.
# /etc/cron.d/sshworkbench-monitors
*/2 * * * * root pgrep -x nginx > /dev/null && curl -fsS https://monitor.sshworkbench.com/api/monitor/ping/def
Your server pings us on its schedule. Missed heartbeats, breached thresholds, or failed runs all turn into email alerts.

What a ping actually carries

Enough to know whether a check passed, and nothing else.

What we receive

  • A ping ID (random token)
  • Timestamp of the ping
  • Optional exit code or value (e.g. disk %)
  • Source IP (transit-only)

What we don't

  • No SSH credentials, no keys, no commands
  • No file contents, no log contents, no command output
  • No process trees, network traffic, or system inventory
  • No long-running connection to your server

Watch the things that take servers down

Eight check types for the usual reasons a server goes down.

Server uptime

Each server checks in on an interval you choose. If it goes quiet, you get an email.

Cron jobs

SSH Workbench wraps the cron line with pings, so you hear about it when a run fails or never happens.

Disk space

A % threshold per mount point. Catch /var or /home filling up before the database stops writing.

Memory

Alerts when RAM use goes above your threshold, often the warning sign before SSH stops responding.

CPU

Alerts when average CPU use goes above your threshold, so a brief spike does not page you.

Services

Pick a process like nginx or postgres. It is checked every 2 minutes and you get an alert if it stops.

SSL certificates

One alert when a certificate gets close to expiry, 30 days out by default. No more surprise Let's Encrypt lapses.

Backups

Alerts if the newest file in a backup folder is older than you allow (26 hours by default), or the folder has no backups.

Stop finding out from users

Set up monitoring across every server in your fleet in a few clicks.

Start free trial