Error paths and alerts that reach a person
🎯You'll be able to
Build an error path whose alerts reach a named owner with what failed, why, and what business record is affected.
🏠The everyday picture
A smoke alarm is useful only if someone hears it. An alarm in an empty building, or one so loud and frequent that people ignore it, protects no one.
📘What it really is
- In DA2 you built an error workflow with the Error Trigger node. Make it useful:
- say which workflow and node failed, the error message, and a link to the execution;
- include a business clue, such as the order ID, so the person knows what's affected;
-
send it where someone will see it in working hours: email, a team chat or WhatsApp.
-
Nodes can also continue on error and send failed items down a separate output. Use this when one bad item shouldn't stop the others, and send those items to a review list.
-
Avoid alert fatigue: group repeated failures into one message, and don't alert on passing errors that a retry fixed.
- Agree who responds and how fast. An alert without an owner is easily ignored.
📝A worked example
Sharma Textiles' alert, after a payment failed to reach the accounts app:
⚠️ Payment → Accounts failed at "Create invoice" (400 Bad Request: GSTIN invalid). Order ST-1187, ₹6,250.00. Open the run: [link]. Owner: Priya (accounts), reply within 4 working hours.
Priya fixes the customer's GST number and retries the run from the link. In the first month, alerts fell from 30 a week (every retry) to 3 a week (only real problems), and each was handled the same day.
🌍Where it's used
- Any production workflow: an error workflow is the basic safety net.
- Client handovers: the client needs to know who receives alerts.
- Order and payment flows, where a missed failure means a missed delivery or a wrong invoice.
📝Case scenario
A client says they've stopped reading automation alerts because they get dozens a day. Most are passing timeouts that a retry later fixed. You turn off alerts for errors that succeed on retry, group remaining failures into an hourly summary, and send payment failures immediately to the accounts person. Alerts drop to a handful a week, and people read them again.
🖱️Try it
Improve your DA2 error workflow so the alert includes the order ID and a named owner. Add a continue-on-error output to one step that handles many items, sending failed items to a review sheet.
⚠️Common mistakes
- Alerts with no business clue. Sign: "Node failed" with no order ID. Fix: include the order or contact ID and a link to the run.
- Alert storms. Sign: the owner gets 40 messages for one problem. Fix: alert once per event or group minor failures into a summary.
🛠️For your project
Project 1 test 8 checks for 1 to 3 alerts naming the order and an owner. The capstone runbook explains what to do for each alert.
✅Quick check
Name three things a good failure alert includes.
Show the answer
Which workflow and node failed, the error message, and a link to the run, plus a business clue such as the order ID.
What is alert fatigue?
Show the answer
When people get so many alerts that they start ignoring them, including the important ones.