Jobs (Heartbeat & Cron Monitoring)

A Job is an inbound heartbeat monitor. Instead of Ionhour reaching out to check on something, your own system reports in. If the expected ping doesn't show up on time, Ionhour assumes the job failed to run and opens an incident.

How It Works

1. You create a Job with an expected schedule (e.g., "runs every hour") and a grace period.
2. Ionhour gives you a unique ping URL for that Job.
3. You add one line to the end of your script or cron task that calls the ping URL whenever the job finishes successfully.
4. If the ping arrives on time, the Job stays healthy. If it doesn't arrive within the schedule plus the grace period, Ionhour marks it late, then down, and alerts your team.

Creating a Job

Sending Your First Ping

Add a single line to the end of your script or cron task that calls the ping URL. The simplest option is a plain GET or POST request:

# Your scheduled job, followed by a ping on success
./run-backup.sh && curl -s https://signal.ionhour.com/api/signals/ping/YOUR_TOKEN

No authentication is needed on the ping URL itself — the token in the URL is what identifies the job, so keep it private (see Best Practices below).

# Run backup every hour, ping Ionhour on success
0 * * * * /usr/local/bin/backup.sh && curl -s https://signal.ionhour.com/api/signals/ping/YOUR_TOKEN > /dev/null

steps:
  - name: Run scheduled task
    run: ./scripts/nightly-build.sh

  - name: Ping Ionhour
    if: success()
    run: curl -s https://signal.ionhour.com/api/signals/ping/${{ secrets.IONHOUR_TOKEN }}

HEALTHCHECK --interval=5m --timeout=10s --retries=1 \
  CMD curl -sf https://signal.ionhour.com/api/signals/ping/YOUR_TOKEN || exit 1

Need to send pings from your own application code instead of a shell script, or want to attach extra details (row counts, duration, dependency status) to each ping? See the API Reference for the full request format.

Schedule and Grace Period

A short grace period (5–15s) suits time-critical jobs where any delay matters. A medium grace period (15–30s) is a safe default for most cron jobs. A longer grace period (30–60s) fits jobs with variable run times or that run on shared infrastructure with occasional startup delays.

Job Status

Every job moves through the same states as a Check:

When a job goes Down, Ionhour opens an incident and notifies your configured alert channels. As soon as the next ping arrives, the job recovers to OK and the incident is resolved automatically.

Viewing and Managing Jobs

The Jobs list works the same way as the Checks list: filter by status, search by name, and switch between a table view and a card/grid view. Each row shows the job's current status, its project, and how long ago its last ping arrived.

Open any job to reach its detail page, which has three tabs:

• Overview — current health, recent incidents, and (if enabled) recent deployments and linked dependencies.
• Integration — the job's schedule and grace period (editable), plus its ping URL and ready-to-copy snippets.
• Events — a log of recent pings, and a reliability view showing how consistently pings have arrived on schedule.

From a job's detail page, you can:

• Pause / Resume — stop or restart monitoring without deleting the job.
• Send a test ping — manually trigger a ping to confirm the integration works before wiring it into your real script.
• Transfer — move the job to a different project within your current workspace.
• Clear events — wipe the recorded ping history.
• Delete — remove the job entirely.

From the Jobs list, each row's ⋮ menu gives you the same Transfer, Clear events, and Delete options. Pause/Resume and sending a test ping are only available from the detail page.

Linking Jobs to Dependencies

If a job's real purpose is to track the health of an external dependency (a third-party API, a database, a queue) rather than a specific project task, you can create the job directly from that dependency's page instead of picking a project. The job then represents the dependency's own heartbeat.

Separately, any job can also be linked to one or more existing dependencies it relies on, so a dependency outage shows up alongside the job's own status. See Dependencies for more.

Best Practices

• Ping only on success. If the job fails partway through, don't send the ping — the missing ping is exactly what should trigger the alert.
• Place the ping at the very end of your script, after everything else has completed.
• Set the grace period realistically. If your job normally takes 10–30 seconds to finish, a 5-second grace period will cause false alarms.
• One job per task. Don't reuse the same ping URL across multiple unrelated jobs — you won't be able to tell which one actually failed.

Next Steps