Monitor GitLab CI Scheduled Pipelines

GitLab's Pipeline Schedules feature runs a pipeline on its own cron-style cadence, independent of pushes and merge requests. UptimeHunt doesn't need to know anything about that schedule — the pipeline just pings a cron monitor as part of its normal job script, using UptimeHunt's own grace period to notice when a scheduled run doesn't happen at all (a paused schedule, a disabled runner, GitLab itself being down).

Create the monitor

Create a cron monitor in Cron Jobs with Fixed interval (or a cron expression matching the schedule you set in GitLab), sized a bit above your pipeline schedule's actual cadence to leave room for scheduling jitter — e.g. a schedule that runs "every day around 03:00" is a fine match for a 0 3 * * * cron expression with a 20–30 minute grace period. Copy its ping URL into a CI/CD variable so it never ends up in your repository:

1. Settings → CI/CD → Variables in the GitLab project.
2. Add UPTIMEHUNT_PING_URL with the monitor's ping URL, and mark it Masked so it never appears in job logs.

Ping only from the scheduled run

Gate the ping job to scheduled pipelines with the CI_PIPELINE_SOURCE predefined variable, so a push or merge-request pipeline never touches the monitor:

nightly-report:
  stage: build
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  script:
    - ./generate-nightly-report.sh
  after_script:
    - |
      if [ "$CI_JOB_STATUS" = "success" ]; then
        curl -fsS -m 10 --retry 5 -o /dev/null "$UPTIMEHUNT_PING_URL"
      else
        curl -fsS -m 10 --retry 5 -o /dev/null "$UPTIMEHUNT_PING_URL/fail"
      fi

CI_JOB_STATUS is a predefined variable available inside after_script with the value success, failed, or canceled — using it there (rather than trying to inspect script's exit code directly) means the ping fires even if script fails outright, since after_script still runs.

Reporting the exit code and a log excerpt

For more detail than a plain success/fail split, capture the job's own exit status and forward the tail of the job log as the ping body — the same exit-code-trap idiom used for a plain crontab entry:

nightly-backup:
  stage: build
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  script:
    - ./run-backup.sh 2>&1 | tee job.log
  after_script:
    - |
      EXIT_CODE=0
      [ "$CI_JOB_STATUS" = "success" ] || EXIT_CODE=1
      curl -fsS -m 10 --retry 5 -o /dev/null \
        --data-raw "$(tail -c 2000 job.log 2>/dev/null)" \
        "$UPTIMEHUNT_PING_URL/$EXIT_CODE"

CI_JOB_STATUS collapses everything to success/failed/canceled rather than a real process exit code, so EXIT_CODE here is a simple 0-or-1 stand-in — enough for the monitor's success/fail state, without claiming a real command exit status it doesn't have.

Related Documentation

• Cron Job Monitoring — curl idioms and schedule grammar in full
• Cron Monitors API Reference
• systemd timers