HHostSSH

Monitoring & alerts

Watch uptime and fleet health, and get paged the moment something breaks — Slack, PagerDuty, webhook, or email.

Monitoring & alerts

HostSSH watches two layers for you and pages you when either breaks:

  1. App health — is each routed domain actually serving?
  2. Fleet health — is each Node online, and are disk, backups, and certs healthy?

The difference that matters: alerts are delivered, not just drawn on a dashboard. An open alert reaches you on the channel you configured, even if you're not looking at HostSSH.

1. App health monitors

Every time you deploy an App with a routed domain, HostSSH auto-creates an HTTP monitor for that domain. You don't set it up — a successful, routed deploy lights it up. The monitor:

  • probes the domain on an interval,
  • classifies it as up / degraded / down,
  • records an uptime series you can see on the App and Observability pages,
  • and opens an alert on a down/degrade transition (and closes it on recovery).

You can also create monitors by hand (for endpoints HostSSH didn't deploy) on the Observability page: HTTP checks, plus richer checks via the DNS and browser add-ons (see Add-ons).

Belt and braces: for a high-stakes migration night, also point an external uptime service at your domain. HostSSH's scheduler runs on your fleet, so an external check gives you an independent second opinion if the box being watched is the box having trouble.

2. Fleet health

The Fleet map turns each Node's heartbeat into live status. HostSSH edge-detects and alerts on:

  • Node offline — heartbeats stopped (degraded after ~3 min, offline after ~15 min).
  • Disk pressure — warns at 65% used, critical at 85%, with one-click cleanup (see below).
  • Backup staleness — no successful capture in the last 24h.
  • Certificate expiry — a renewal that didn't happen surfaces before the cert dies.

These are computed on the scheduler tick and delivered, so a transition (healthy → broken) pages you rather than waiting for you to notice.

3. Setting up alert channels

Configure where alerts go in Settings → Alerts (or via Agent/control-plane environment). Any combination of:

ChannelEnv / settingNotes
SlackHOSTSSH_ALERT_SLACK_WEBHOOKAn incoming-webhook URL.
PagerDutyHOSTSSH_ALERT_PAGERDUTY_KEYEvents API routing key.
Generic webhookHOSTSSH_ALERT_WEBHOOKPOSTs a JSON alert to any URL.
EmailHOSTSSH_ALERT_EMAIL_TO / HOSTSSH_ALERT_EMAIL_FROMUses the email add-on / your SMTP.

An alert has a lifecycle: it opens on the breaking transition, you can acknowledge it, and it closes automatically on recovery. Acknowledged alerts stop re-paging while you work the incident.

4. Disk-pressure cleanup

When a Node crosses the disk warning/critical thresholds, the Fleet drawer offers one-click cleanup. It's deliberately conservative — it reclaims rebuildable artifacts only:

  • old app image versions (keeps the newest few per App),
  • dangling images,
  • bounded build cache.

It never touches named volumes, running containers, rollback tags, .hsi images, or user media/uploads. You can preview (dry-run) the exact reclaim before running it, and see the reclaimed GB afterward. Customer data is archive-first: capture to .hsi/restic, never cron-deleted.

5. Network telemetry (Mesh)

The Mesh page shows the private WireGuard network linking your Nodes — peer links, handshake freshness, and the health of the database bridge. This is where you confirm that App-to-database traffic is flowing privately and that no Mesh peer has gone stale.

6. Observability at a glance

The Observability page consolidates:

  • uptime series per monitored domain,
  • open/acknowledged/closed alerts,
  • fleet resource trends (CPU/memory/disk over time),
  • recent Jobs and their outcomes.

For programmatic scraping, the control plane also exposes a Prometheus-format /metrics endpoint and a /healthz readiness endpoint.

7. A sensible starting configuration

For a small fleet:

  1. Set one always-on channel (Slack or email) and one wake-me channel (PagerDuty) for criticals.
  2. Leave the auto app-health monitors on (they are by default).
  3. Add an external synthetic check on your most important domain.
  4. Confirm nightly backups are scheduled (see Backups & recovery) — the backup-staleness alert only helps if a schedule exists to be stale against.

Next steps