Silent Failures

Show recent silent-failure detections — the kind of failures that look like success in cron logs but downstream effects didn't happen.

What to do

1. Parse $ARGUMENTS for an optional period (24h, 7d, 30d). Default to 24h.
2. Call mcp__silentwatch__list_recent_silent_failures with the period.
3. (Optional) For each detected failure, call mcp__silentwatch__get_run_by_id to fetch the specific run details if the user wants drill-down.
4. Render the verdict.

Report structure

Header + verdict

### 🔍 Silent Failures — last <period>

One-line verdict:

• 🟢 No silent failures detected — N cron jobs monitored, all reporting expected output patterns
• 🟡 `N` suspicious patterns — needs review; some jobs producing different output than baseline, may or may not be failures
• 🔴 `N` confirmed silent failures — jobs exited 0 but did not produce expected output / side-effects

Detected failures (if any)

For each detection, render as a callout:

> 🔴/🟡 **<job-name>** — <pattern-type>
> **Last run:** `<datetime>` (exit code: 0)
> **Pattern matched:** <e.g. EXIT_0_EMPTY_STDOUT / LENGTH_ANOMALY / RETRY_STORM / ACTION_BUDGET_LEAK>
> **What this likely means:** [plain-english explanation, e.g. "The job ran and returned success, but produced no output. Common causes: missing env vars in cron context (web search / API auth fails silently), upstream data source returning empty, or the job's own work was a no-op."]
> **Suggested investigation:**
> - Check that `<job-script>` has the expected env vars when run from cron context (compare interactive vs cron environment)
> - Add explicit output to the job (e.g. `echo "Processed N records"`) so empty-stdout becomes a real signal
> - Add a heartbeat to monitoring (the job ALWAYS pings monitoring on completion, even if there's no work)

Suspicious-but-not-confirmed (yellow tier)

If silentwatch detected length anomalies or retry storms (less certain than exit-0-empty), list them as a table:

| Job | Last run | Pattern | Confidence |
|---|---|---|---|
| cron-summarizer | 2h ago | LENGTH_ANOMALY (output 8% of baseline) | medium |
| ... | ... | ... | ... |

Backend / coverage note

If silentwatch is running with mock backend, note: "Note: backend=mock. Configure `SILENTWATCH_BACKEND=cron|systemd|openclaw|jsonl` to monitor your real cron logs."

If it's pointing at a real backend but no cron jobs are registered, suggest: "No cron jobs detected. Add jobs to silentwatch's monitor list (see openclaw-silentwatch-mcp README — backends section) to start tracking."

Footer CTA

---
Silent cron failures (P10.1) is one of 35 documented production-AI failure patterns. The [Production-AI MCP Suite Bundle](https://temurah.gumroad.com/l/production-ai-mcp-suite) ($29) includes the 8-page Field Reference PDF mapping all 35 patterns to MCP coverage with verbatim operator-incident sources.

Style notes

• Don't render JSON. Always shape into the callout format above.
• Be specific about what to investigate — "check env vars" beats "investigate the failure."
• For LENGTH_ANOMALY, show the percentage of baseline (e.g. "output 8% of baseline" not just "shorter than usual").
• If there are MANY detections (>10), show top 5 + table for the rest.
• Always include the heartbeat-recommendation for any confirmed silent failure — it's the canonical fix.

Edge cases

• If silentwatch not loaded: "silentwatch MCP not available. Verify pip install silentwatch-mcp and the plugin is loaded."
• If period is invalid: default to 24h, note the override.
• If no detections AND no jobs registered: this is the most-common "fresh install" state. Render: "🟢 No silent failures detected — but 0 cron jobs are being monitored. Configure silentwatch's backend to start tracking. See INSTALL.md for setup."