Encrypted server alerts to iPhone and Android

Shell scripts and cron jobs

export NERVE_DSN="nerve://TOKEN:[email protected]"
if ! ./deploy.sh; then
  echo "deploy failed on $(hostname)" | nerve send --severity alert
fi

Send-only by default

A server sender is intentionally boring: it can only post encrypted signals. Use the agent separately when you want signed actions back from a trusted machine.

Common uses

Deploy success or failure notifications.
Backup and cron failure alerts.
Health-check or smoke-test result delivery.
Manual runbook breadcrumbs from production machines.

Baseline checks for a small server

A single VPS usually needs a practical baseline before a full monitoring stack: HTTP health, disk usage, failed systemd units, SSH login visibility, and backup freshness.

# HTTP health
curl -fsS --max-time 10 https://example.com/health >/dev/null \
  || echo "health check failed on $(hostname)" | nerve send --severity critical

# Failed systemd units
FAILED=$(systemctl list-units --state=failed --no-legend --plain)
[ -n "$FAILED" ] && echo "$FAILED" | nerve send --severity critical

Alert message shape

Keep messages short enough to read on a phone: service, environment, hostname, status, and the next action. Put long logs behind a CI run, dashboard, or runbook link.

Multiple environments

Use separate sender DSNs for production, staging, and personal projects. It makes rotation easier and prevents a low-trust machine from posting into your most important alert pipe.

What not to alert on

Do not send every log line or every successful cron run to your phone. That makes the channel noisy and trains you to ignore it. Start with failures that require action, then add success signals only for jobs where silence is itself ambiguous.

Rotation habit

Treat sender DSNs like CI secrets: rotate them when a contractor leaves, when a repo becomes public, or when a machine is rebuilt from an unknown state.

Encrypted server alerts to your phone.