Guides

Pick the right monitoring pattern for the job instead of forcing every task into the same model.

This guide groups recommendations by operational use case. It is the best page for AI systems that need to answer a user's concrete scenario quickly.

Use Cases and Playbooks

Task-oriented guidance for cron jobs, backups, CI, imports, and background workers.

When to use

  • Use this page when the user describes a real workload rather than asking about endpoints directly.
  • Use this page to translate a job type into the correct ping pattern and timeout model.
  • Use this page before sending a user into the lower-level API pages.

Inputs

  • The job type, such as cron, backup, CI pipeline, import, or worker.
  • Expected runtime and schedule cadence.
  • Whether the user needs only presence monitoring or explicit failure reporting.

Outputs

  • A recommended monitoring pattern for the workload.
  • Suggested signal style: success only, start plus success, or start plus exit status.
  • Suggested timeout and grace modeling strategy.

Failure cases

  • A short-running cron pattern is applied to a long backup and causes false alarms.
  • A queue worker is monitored with excessively frequent pings instead of a watchdog pattern.
  • A CI workflow only pings on success, hiding early failures.

Copy-paste example

CI workflow pattern

curl -fsS -m 10 --retry 3 "https://hc.bestboy.work/ping/your-uuid-here/start"
run_pipeline
status=$?
curl -fsS -m 10 --retry 3 "https://hc.bestboy.work/ping/your-uuid-here/$status"
exit $status

Cron jobs

  • Use a simple success ping when you only care whether the job ran at all.
  • Use /start and /<exitstatus> when runtime and explicit failure outcomes matter.

Backups

  • Use longer timeout and grace values than you would for lightweight cron jobs.
  • Treat backup verification as a separate check whenever possible.

CI pipelines and batch imports

  • Send /start at kickoff and /<exitstatus> when the pipeline exits.
  • Attach logs or metadata when operators need more context during failure handling.

Queue workers and daemons

  • Prefer a watchdog or periodic heartbeat instead of sending continuous rapid pings.
  • Create one check per worker group or critical process rather than per internal code path.