Skip to content
Last updated July 2, 2026

Cron Jobs

The agent already knows what cron is scheduled on each server. Cron Jobs rolls all of that up into one screen so you can answer “is anything scheduled to run tonight?” without SSHing to twenty boxes.

Open Cron Jobs in the sidebar (route /cron-jobs). KPI strip at the top:

  • Total jobs across the fleet.
  • Servers that have any cron scheduled.
  • Monitored — jobs already linked to a heartbeat.
  • Unmonitored — jobs that would silently fail with no signal to you.

Below the strip, jobs are grouped by server. Each server card shows a table with:

  • Schedule — the raw cron expression, and a human translation (“Every day at 03:00”).
  • Command — the command line to run. Sensitive fragments like passwords, tokens, and API keys in the command line are masked in the UI.
  • User — the account cron runs the job as.
  • Monitoring — a green check-plus-name link to the heartbeat if one is attached, or “Not monitored” otherwise.
  • Discovered — when the agent first saw the job.

Empty state: if the agent hasn’t reported cron entries yet, the page says so and points you at the agent.

  • Attach a heartbeat to a job that’s currently unmonitored — clicks through to Heartbeats where you finish the wiring on the server side.
  • Filter — narrow to a single server by clicking its hostname.
  • Paginate through very large fleets.
  • The HostAtlas agent enumerates user and system crontabs on the box and reports them on its regular sync. Discovery is passive — HostAtlas does not write cron entries.
  • Sensitive substrings in command lines (things that look like passwords, bearer tokens, API keys) are redacted before storage so the UI never renders them in plain text.
  • Heartbeat linkage is inferred when a job’s command posts to a HostAtlas heartbeat URL.
  • Heartbeats — attach a monitor to a job that must run on cadence.
  • Automations — HostAtlas-managed scheduled work, as an alternative to cron.
Was this page helpful?