ankos watch

ankos watch runs continuous PCI monitoring locally. On a schedule, it re-scans the same scope as a baseline directory, compares the result against it, and posts an alert whenever posture regresses — a new degradation or lost coverage. It's the long-running counterpart to scheduling ankos drift from cron or CI: for teams that prefer a daemon to a CI scheduler.

Like drift, the provider, region/scope, and collectors are inferred from the baseline, so it works for AWS, GCP, GitHub, Okta, Entra, and Kubernetes baselines alike.

Synopsis

ankos watch <baseline-dir> [flags]

You must give it a cadence: --schedule (cron), --interval (a duration), or --once (a single cycle).

Quick start

# Re-scan every night at 02:00 and alert Slack on regression
ankos watch ./ankos-evidence-baseline \
  --schedule "0 2 * * *" \
  --webhook "$SLACK_WEBHOOK_URL"

# Re-scan every 12 hours and refresh the Ledger each run
ankos watch ./ankos-evidence-baseline --interval 12h --upload

# Run a single cycle and exit with a CI-style code (useful for testing)
ankos watch ./ankos-evidence-baseline --once --fail-on any

Flags

Use exactly one of --schedule or --interval (or --once on its own).

Cadence

• --schedule takes a standard 5-field cron expression and runs at each matching time. Use it for calendar-aligned monitoring ("every night at 02:00", "every Monday at 06:00").
• --interval takes a Go duration (30m, 6h, 12h) and runs that often from when you start it. The minimum interval is 1m.
• --once runs a single cycle and exits. Combined with --fail-on, this gives you a CI-style exit code — handy for testing a watch configuration or wiring one cycle into a pipeline.

The daemon prints the next run time before each cycle. Stop it with Ctrl-C.

Alerting

When posture regresses, watch posts an alert to the configured --webhook (alias --notify). A Slack incoming-webhook URL (hooks.slack.com/...) is rendered as a Slack message; any other URL receives the same alert as a generic JSON payload, so it works with a custom endpoint or a relay. Nothing is sent unless a webhook is configured, and a delivery failure is logged but never crashes the daemon.

As a long-running watcher, the daemon keeps running past a regression rather than exiting on the first one — the alert is the signal. To gate a build on drift instead, use --once --fail-on … (or schedule ankos drift from CI).

watch vs. drift

Both infer the provider and scope from the baseline, both support --webhook and --upload, and both are read-only. Pick drift when a scheduler already runs your jobs; pick watch when you want a single long-running process to own the cadence.

Exit codes