Skip to content

Health monitor

Health monitor #117

Workflow file for this run

name: Health monitor
# External-ish monitoring for the radar pipeline (audit: "if the pipeline dies
# silently, nobody notices"). Runs on its own schedule, reads the PUBLISHED
# Pages data, and maintains a single alert issue when the data goes stale or
# the last run recorded a failure. Closes the alert automatically on recovery.
on:
schedule:
# Every 3h, offset from the engine (:17) and the sync (:37). A monitor
# that runs every 12h against a 12h threshold cannot see an outage shorter
# than ~24h — which is how a 7h freeze stayed green with every badge
# passing. The check reads two small JSON files; running it 8x a day costs
# seconds on a public repo and cuts worst-case detection to ~10h.
- cron: "43 */3 * * *"
workflow_dispatch:
permissions:
issues: write
contents: read
concurrency:
group: axonos-radar-health
cancel-in-progress: false
jobs:
health:
name: Data freshness check
runs-on: ubuntu-latest
timeout-minutes: 10
env:
GH_TOKEN: ${{ github.token }}
GITHUB_TOKEN: ${{ github.token }}
steps:
- uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
- name: Check published data freshness
run: python3 scripts/health_check.py
- name: Commit provenance readout
# Data commits are written through the Contents API. GitHub signs those
# when the caller is an App identity (a workflow's GITHUB_TOKEN); the
# same API called with a user PAT produces an unsigned commit. The files
# land identically either way, so this is the only place the difference
# shows. Report-only: a rate-limited API is not a repository defect.
run: |
python3 scripts/check_provenance.py --limit 30 | tee -a "$GITHUB_STEP_SUMMARY"