For a hand-rolled cron job or systemd timer, your script calls a ping URL. For a Kubernetes CronJob, the operator does the reporting on the workload's behalf, over the authenticated API — it never touches the monitor's ping token. Both paths land on the exact same CronMonitor resource and the exact same missed-ping sweeper.

If Kubernetes itself skips a scheduled occurrence — no Job created at all, which can happen with concurrencyPolicy: Forbid/Replace or a startingDeadlineSeconds miss — the operator has no event to report, because none occurred. UptimeHunt's own missed-ping sweeper is what turns "no run showed up within schedule + grace" into an incident, exactly as it would for a hand-rolled job that silently stopped running.

When the operator creates a monitor from a CronJob, you can still edit it directly in UptimeHunt — change the grace period, enable drift detection, tune its baseline/threshold, add a max runtime, pause it, or edit its settings. On every reconcile the operator re-applies schedule/timezone/metadata plus any field you've set via annotation — a field you leave annotation-free keeps whatever you last set in the dashboard. See Annotations below for exactly which fields that covers and how removing an annotation behaves.

When spec.timeZone is set, it's sent verbatim as the monitor's timezone. When it's unset (nil), the operator defaults the monitor's timezone to UTC — but that is not what Kubernetes itself does. A CronJob with no spec.timeZone is actually scheduled by the kube-controller-manager process's local timezone, which the operator has no way to read from the CronJob object. If your cluster's controller-manager doesn't run in UTC, a monitor defaulted to UTC will disagree with when the job actually fires, and you'll see spurious "late"/"down" states around the offset.

Set spec.timeZone explicitly (GA since Kubernetes v1.27) on any CronJob running on a non-UTC cluster:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-db-backup
spec:
  schedule: "0 4 * * *"
  timeZone: "Europe/Warsaw"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: my-backup-image:latest
          restartPolicy: OnFailure

Unlike some non-Kubernetes cron implementations, you cannot prefix spec.schedule with CRON_TZ=Europe/Warsaw or TZ=Europe/Warsaw — the Kubernetes API server itself rejects a spec.schedule that isn't a bare 5-field expression or @macro, before the operator or UptimeHunt ever see it. spec.timeZone is the only place a CronJob's timezone belongs.

The grace annotation and the drift/runtime annotations above are entirely optional — set one and the operator pushes that value on every reconcile, overriding any dashboard edit to that same field in the meantime; leave a field annotation-free and the operator omits it from the upsert, so a dashboard edit to it is preserved untouched. This is the mechanism that makes autodiscovered monitors editable at all. Removing an annotation you'd previously set does not revert the field back to a default — the field simply stops being touched by the operator going forward and keeps whatever value it currently holds. The one true "turn it off" lever is setting drift-enabled: "false" explicitly.

Only the operator ever sets or clears suspended — it never touches the monitor's user-controlled paused flag, and the sweeper suppresses alerts for either one. So if you manually Pause a monitor in the UI and someone later un-suspends the CronJob (spec.suspend: false), the monitor stays paused — un-suspending in Kubernetes can't silently override a pause you set by hand. To fully resume, both suspended and paused need to be cleared (spec.suspend: false on the CronJob, and Resume in the UI).

Unlike Ingress checks, the cron monitors API has no lookup-by-source route yet, so the operator can only prune a monitor whose id is still in its own in-memory cache from an earlier upsert in the same process. A cold cache — right after the operator restarts, before that CronJob has been reconciled again — means the prune is skipped (logged, not silently dropped). If you need a guaranteed removal, delete the monitor directly in UptimeHunt.