Production executions barely moved, so the spike is not explained by a volume burst.
Failed executions rose from an estimated ~630 to 1,424, which is a real regression signal.
The hourly audit showed a Gmail/n8n backup error: HTTP Error 400: Bad Request.
The live monitor repeatedly timed out on SSH + osascript, which points to the Mac-side path, not n8n alone.
A lot of cron jobs were manually paused on the VPS. Any workflow depending on them can look “failed” simply because it was intentionally taken out of service.
The email audit returned a Gmail/n8n HTTP 400. The live monitor returned an SSH/AppleScript timeout. Those are genuine operational errors, not just false positives from a pause.
This explains why the dashboard may look worse than the truly active surface area.
The audit hit an HTTP Error 400: Bad Request path while checking the backup flow.
Repeated osascript timeouts show the live-monitor path is brittle or blocked.
Lower than 64.4%, because you knowingly paused some jobs.
Even after discounting pauses, the backup email route and Mac mini path still need attention.
Compare active workflows only vs all workflows to separate operational cleanup from true failure rate.
| Job / workflow | Evidence seen in chat | Likely classification | Impact on failure stats |
|---|---|---|---|
| Raziel Hourly Email Audit /root/raziel-projects/zero-cost-gmail-monitoring/hourly_email_audit.py |
Run log showed HTTP Error 400: Bad Request after confirming n8n and Mail were already running. | Real issue | High — this is a real backup-path failure, not just a disabled-job artifact. |
| Raziel Live Email Monitor /root/raziel-projects/zero-cost-gmail-monitoring/live_email_monitor.py |
Repeated SSH command timeouts while launching osascript on the Mac mini. | Dependency brittle | High — the live path is likely a genuine operational bottleneck. |
| Raziel Inbox Monitor n8n inbox force-trigger / NAS polling |
Observed as silent/empty output in one run, and the workflow was part of the “monitoring stack” that depends on other services. | Possibly benign / paused | Moderate — could be inflated by intentional disablement or quiet periods. |
| Paused VPS cron jobs multiple scheduled workers paused by you |
You said you paused a lot of cron jobs that may have dependencies with n8n workflows. | Intentional / excluded | Medium to high — definitely makes the raw rate look worse if still counted in recent history. |
That’s the exact upgrade-worthy view: not just a number, but a breakdown by job state, error signature, and whether the failure is policy-driven or operational.
Production volume 2,210; failed executions 1,424; run time 0.31s; failure rate up 35.7 points. That was the initial red flag.
You said you paused several VPS cron jobs that may depend on n8n workflows. That means some of the raw failure stats are likely inflated by intentional disablement.
The latest audit log showed HTTP Error 400: Bad Request and confirmed the n8n/Mail services were already running.
Repeated ssh ... osascript - calls timed out after 30 seconds, which points to the Mac mini dependency path rather than n8n alone.
Flat volume + sharply rising failures = something changed.
So the raw dashboard probably overstates live failure risk.
Gmail backup and Mac mini SSH/GUI are the priority fix targets.
Separate active workflows from intentionally paused jobs so you can compute an adjusted failure rate.
The HTTP 400 needs inspection from the OAuth / token refresh branch, not another generic retry.
That live-monitor timeout can easily cascade into false operational noise across other automations.
If you later want a live version, the same layout can be wired to n8n exports or API responses and turned into a real dashboard instead of a forensic snapshot.