Draft — in editorial review, not yet published. Content has not been approved by a human reviewer.
Lesson 20 / 50 · Version 2.2.0
Production Automation Monitoring
- Level
- Intermediate
- Duration
- 15 min learn + 15 min apply
- Prerequisites:
- Lessons 11–19
Why it matters: Automations rot quietly: a field gets renamed, a token expires, a rule stops matching. Monitoring outcomes, with owners and runbooks, is what keeps them working after the builder moves on.
By the end you can:
- Choose operational and business metrics
- Write actionable alerts
- Create a runbook
- Manage changes with testing and rollback
Learn (15 min)
1. Observe outcomes, not just runs (5 min)
Track: success/failure counts, duration, retries, queue backlog, duplicates, and business outcomes (e.g., "leads assigned within 1 hour"). Reconcile with the destination system periodically: count records created by the workflow vs. expected. Logs often hold personal data, so limit what you keep and who can read it.
2. Alert on conditions someone owns (5 min)
| Alert | Threshold | Owner | First response |
|---|---|---|---|
| No lead assignments | 0 in 4 business hours | Ops lead | Check trigger + auth |
| Auth errors | ≥3 in 1 hour | Integrations owner | Reconnect credentials |
| Duplicate spike | >5% of new contacts/day | Ops lead | Pause; inspect dedupe step |
| Test the alert path itself, so a failed alert doesn't fail silently. |
3. Operate changes safely (5 min)
Keep a record per workflow: purpose, owner, dependencies, data classification, credentials, schedule, recovery steps. Test changes on a copy with sample data, record what changed, and know how to roll back. Review connected accounts and permissions periodically, and when staff or tools change.
Apply (15 min)
Worked example (3 min). Failure rate jumps to 10% after a connected app renames a field. Response: (1) pause risky downstream actions; (2) inspect recent executions; (3) identify affected records and the changed field; (4) notify the owner; (5) fix the mapping in a test copy, replay failed items with dedupe, verify records, and add an alert for schema changes.
Lab (7 min): Write a runbook page.
- Choose a workflow you built or use.
- Complete the record: purpose, owner, systems, data types, credentials location, schedule.
- Add three known failures with symptom → check → fix.
- Add one alert (threshold, owner, first response) and one rollback step.
Deliverable: A one-page runbook. You're done when: A new teammate could handle your most likely failure from the page alone.
Check yourself (5 min)
- Why monitor business outcomes as well as run status?
- What makes an alert actionable?
- Scenario: Alerts go to a shared inbox no one reads. What do you fix?
- When do you review credentials?
- What belongs in a runbook?
Reference
Common mistakes
| Symptom | Likely cause | Fix |
|---|---|---|
| "All green" but wrong data | Run status only | Add outcome checks and reconciliation |
| Noisy alerts ignored | No thresholds/owners | Tune; assign ownership |
| Fix breaks something else | Edited production live | Test copy + rollback plan |
Cheat sheet: Measure outcomes → alert on owned conditions → investigate → recover safely → document → review access and changes.
Key terms: execution history, alert threshold, runbook, rollback, reconciliation.
Interview prompts: What do you monitor for a lead-routing workflow? How do you handle a vendor changing an API?
Go deeper: n8n executions · n8n error workflows · Make scenarios · NIST Cybersecurity Framework
Next: Track 3 — the business apps you'll connect (Lesson 21).