How do you monitor a cron job’s output?

How do you define the scheduled Check?

Create the Check with a full-access API key, bearer authentication, and no X-Entity header. The endpoint uses PUT replace semantics: send the full desired configuration every time because omitted configurable fields reset to their defaults.

curl --request PUT \
  https://glnc.io/api/v1/monitoring/checks/catalog-sync \
  --header "Authorization: Bearer $GLNC_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "display_name": "Nightly catalog sync",
    "category": "catalog",
    "schedule_cron": "0 2 * * *",
    "schedule_timezone": "America/New_York",
    "warn_threshold_seconds": 900,
    "error_threshold_seconds": 1800,
    "output_expectations": [
      {
        "field": "records_created",
        "operator": "<",
        "value": 50,
        "severity": "critical"
      }
    ]
  }'

PUT replaces the configurable Check fields. Include the display name, schedule, thresholds, output rules, and any triage context on every configuration sync.

How does the cron job report a run?

After the cron job finishes, send its terminal status and output metadata to the Check’s Runs endpoint. Keep the API key in an environment variable; $GLNC_API_KEY below is a placeholder, not a credential.

curl --request POST \
  https://glnc.io/api/v1/monitoring/checks/catalog-sync/runs \
  --header "Authorization: Bearer $GLNC_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "status": "succeeded",
    "metadata": { "records_created": 42 }
  }'

How does Glnc keep schedule timing accurate?

The Check pairs its cron expression with an IANA timezone such as America/New_York. Glnc evaluates the most recent expected calendar slot in that timezone. Lateness thresholds apply after the slot, while a bounded grace window accepts a slightly early Run for that slot.

How do you verify the job’s output?

The example’s critical rule goes Critical when records_created < 50. A Run reporting 42 records trips it and is marked failing even though its execution status is succeeded. A later Run with { "records_created": 54 } does not trip the rule.

When should you report start and completion separately?

Use separate signals when it matters whether the job began near its schedule and whether it stayed within a duration budget. Report started first, then complete that open Run with succeeded, failed, or timed_out and its final metadata.