/monitor-continuous

description: Run recurring compliance checks and emit machine-readable alerts

Monitor Continuous

Runs a single pass of recurring compliance monitoring: orchestrates `/grc-engineer:gap-assessment`, applies warn/critical thresholds per framework, optionally chains `/grc-engineer:record-automation-metrics`, and emits a structured JSON summary suitable for cron, GitHub Actions, Slack, email, or PagerDuty.

Implementation: [`scripts/monitor-continuous.js`](../scripts/monitor-continuous.js).

Usage

/grc-engineer:monitor-continuous <frameworks> [options]
/grc-engineer:monitor-continuous --config=<path>

The host scheduler (cron, EventBridge, GitHub Actions) provides recurrence; this command executes one monitoring pass per invocation. The `schedule` value is recorded in the output summary so downstream dashboards can group runs by cadence.

Arguments

• `<frameworks>` - Comma-separated frameworks (e.g. `SOC2,PCI-DSS,NIST-800-53`).

Required unless supplied via `--config`.

Options

• `--config=<path>` - YAML or JSON config (see below). CLI flags override config values.
• `--sources=<csv>` - Connectors whose cached findings should feed the assessment.
• `--schedule=<name>` - Label only (`daily`, `weekly`, `hourly`). Recorded in output.
• `--report-dir=<path>` - Where gap-assessment writes its bundle (default: `./monitor-continuous-<run_id>/`).
• `--output=<path>` - Write the JSON summary to this path. stdout always gets it too.
• `--warn-threshold=<0..1>` - Per-framework pass-rate warning floor (default: `0.90`).
• `--critical-threshold=<0..1>` - Per-framework pass-rate critical floor (default: `0.80`).
• `--record-metrics` - After assessment, run `record-automation-metrics.js`.
• `--metrics-config=<path>` - Config for record-automation-metrics (implies `--record-metrics`).
• `--window-label=<label>` - Forwarded to record-automation-metrics.
• `--cache-dir=<path>` - Forwarded to gap-assessment (finding cache dir).
• `--offline` - Use the local SCF cache only (no network).
• `--no-exit-code` - Always exit 0 even on threshold breach.
• `--quiet` - Suppress stderr progress.
• `--dry-run` - Resolve config + print planned actions; no subprocess runs.

Examples

# Single pass over three frameworks using cached findings
node plugins/grc-engineer/scripts/monitor-continuous.js SOC2,PCI-DSS,NIST-800-53

# Daily monitoring driven by a config file
node plugins/grc-engineer/scripts/monitor-continuous.js \
  --config=plugins/grc-engineer/examples/monitor-continuous.yaml

# Chain automation-metrics snapshot on the same run
node plugins/grc-engineer/scripts/monitor-continuous.js SOC2 \
  --metrics-config=./automation-metrics.yaml --window-label=current-week

# Dry-run to validate config without spawning subprocesses
node plugins/grc-engineer/scripts/monitor-continuous.js \
  --config=./monitor-continuous.yaml --dry-run

Exit codes

• `0` - All frameworks at or above the warning threshold.
• `2` - At least one framework below the warning threshold.
• `3` - At least one framework below the critical threshold.
• `1` - Usage error or subprocess failure.

Set `--no-exit-code` to always exit 0 (for example, when a CI step must continue running downstream notification steps regardless of status).

Config file

YAML or JSON. Example: [`examples/monitor-continuous.yaml`](../examples/monitor-continuous.yaml).

frameworks: [SOC2, PCI-DSS, NIST-800-53]
schedule: daily
sources: [aws-inspector, github-inspector]
thresholds:
  warning: 0.90
  critical: 0.80
report_dir: ./monitor-reports
record_metrics:
  enabled: true
  config: ./automation-metrics.yaml
  window_label: current-week

Output contract

stdout is a single JSON document. Downstream alerting tools (Slack, email, PagerDuty) should key off `summary.overall_status`, `alerts[]`, and `framework_results[].status`.

{
  "schema_version": "1.0.0",
  "kind": "monitor_continuous_run",
  "run_id": "20260424T140000-a1b2c3d4",
  "generated_at": "2026-04-24T14:00:00Z",
  "schedule": "daily",
  "frameworks": ["SOC2", "PCI-DSS", "NIST-800-53"],
  "sources": ["aws-inspector", "github-inspector"],
  "thresholds": { "warning": 0.9, "critical": 0.8 },
  "framework_results": [
    {
      "framework": "SOC2",
      "evaluated": 50,
      "passing": 49,
      "failing": 1,
      "inconclusive": 0,
      "total_controls": 64,
      "pass_rate": 0.98,
      "pass_rate_pct": 98,
      "coverage_pct": 78,
      "status": "ok"
    }
  ],
  "summary": {
    "overall_status": "warning",
    "overall_pass_rate": 0.92,
    "tier1_blockers": 3,
    "tier2_findings": 7,
    "tier3_recommendations": 4,
    "passes": 118,
    "inconclusive": 2
  },
  "alerts": [
    {
      "severity": "warning",
      "framework": "PCI-DSS",
      "pass_rate": 0.86,
      "threshold": 0.9,
      "message": "PCI-DSS pass rate 86.0% below warning floor 90%"
    }
  ],
  "artifacts": {
    "gap_report_dir": "./monitor-reports",
    "metrics": { "skipped": false, "failed": false }
  },
  "gap_assessment_summary": { "...": "pass-through from gap-assessment.js" }
}

What this command does not ship

By design, the runner is transport-agnostic. It does **not** POST to Slack, send email, or page on-call. Those steps live in the host scheduler (examples below), so the same run output can drive any combination of channels.

For trend analysis over time, consume the JSON output (or the `grc-data/metrics/` snapshots written when `record_metrics` is enabled) with a reporting workflow such as `/report:exec-summary`.

If you only need scheduled automation-history snapshots for the PR #54 reporting flows, use the copy-pasteable GitHub Actions template at [`examples/github-actions/automation-metrics-snapshot.yml`](../examples/github-actions/automation-metrics-snapshot.yml).

Setup

1. Stage a config file

Copy `plugins/grc-engineer/examples/monitor-continuous.yaml` to your project root and edit the framework list, thresholds, and optional `r