DA6: Reliable automations

Why each option is right or wrong

• “Keep the 5 retries; the app may recover” (Incorrect): A 401 comes from the credentials, not a short outage, so every retry fails the same way.
• “Raise the retries to 10 with longer waits” (Incorrect): More retries only delay the alert; the error won't clear by itself.
• “Switch to a different accounts app” (Incorrect): The app works; the connection's credentials need attention.
• “No retries for 401; alert a person” is correct.

  "401 Unauthorized" is a lasting error: the key has expired, been changed or lost access. Retrying gives the same result. An alert to the credential's owner gets it fixed, and the failed run can then be retried from the link.

  • Retry instead: 429, 503 and timeouts.
  • Alert includes: the order ID and run link.

📖 Revise: Lesson 1: Retries and passing failures

Why each option is right or wrong

• “Retry the 200 failures immediately” (Incorrect): Instant retries add more calls at the busiest moment and hit the limit again.
• “Buy a second WhatsApp number and split the list” (Incorrect): That adds cost and complexity before trying the simple fix of pacing the sends.
• “Drop the 200 failed contacts from the list” (Incorrect): The contacts were fine; the sends were too fast.
• “Send in batches with pauses, and retry with waits” is correct.

  A 429 means too many calls too quickly. Batches of, say, 50 with a pause between them keep within the limit, and retries with a wait catch the few that still hit it. Retrying instantly would make it worse.

  • Check: the API's stated limit per minute.
  • Log: sent, failed and retried counts.

📖 Revise: Lesson 1: Retries and passing failures

Why each option is right or wrong

• “Send the alerts to a second person as well” (Incorrect): Two people ignoring the same flood doesn't help.
• “Turn off the error workflow until things calm down” (Incorrect): Then real failures, such as payment problems, would go unnoticed.
• “Make the alert messages shorter” (Incorrect): Shorter messages don't reduce the number of alerts, which is the real problem.
• “Alert only when a person is needed” is correct.

  This is alert fatigue. Errors that a retry fixed don't need anyone, so they shouldn't alert. Grouping the remaining minor failures into a summary, while sending payment failures straight away, makes each alert worth reading.

  • Owner: a named person for each alert type.
  • Measure: alerts per week before and after.

📖 Revise: Lesson 2: Error paths and alerts that reach a person

Why each option is right or wrong

• “Remove the GST field from all invoices” (Incorrect): Invoices need correct GST details for the business's tax records.
• “Process one order per day to reduce risk” (Incorrect): That slows the business down and doesn't handle the bad data.
• “Retry the whole batch until it succeeds” (Incorrect): The invalid GST number is a lasting error; retrying the batch fails every time.
• “Continue on error and send failed items to review” is correct.

  One bad item shouldn't block 39 good ones. With continue-on-error, failed items go down a separate output to a review list with the error, the 39 invoices are created, and a person fixes the one problem order.

  • Alert: one message listing the failed orders.
  • Retry: the fixed order on its own.

📖 Revise: Lesson 2: Error paths and alerts that reach a person

Why each option is right or wrong

• “Stop retrying failed runs” (Incorrect): Retries are needed to recover failed runs; they need to be safe instead.
• “Ask the customer to ignore the second invoice” (Incorrect): It confuses the customer and the business's accounts.
• “Put the invoice step after the CRM step” (Incorrect): A failure at the invoice step would then leave the CRM updated without an invoice, and repeats would still duplicate.
• “Check for an existing invoice before creating one” is correct.

  The step wasn't idempotent: running it again made a second invoice. Checking for an invoice with that order ID first, and marking the order processed only after every step succeeds, lets a retry skip what's done and finish the rest.

  • Pattern: look up by a unique ID, then create or skip.
  • Test: fail the CRM step on purpose, then retry.

📖 Revise: Lesson 3: Duplicates and safe repeats

Why each option is right or wrong

• “The customer's phone number” (Incorrect): One customer can make many payments, so real later payments would be skipped.
• “The time the webhook arrived” (Incorrect): A resent event arrives at a different time, so it would look new.
• “The order total in paise” (Incorrect): Different orders can have the same total.
• “The payment_id” is correct.

  The payment ID identifies this one payment, however many times the event is sent. Recording it after processing and checking it first makes repeats harmless. The event ID also works for exact resends, but the payment ID catches every notice about the same payment.

  • Store in: a database table with a unique key, so even two copies arriving at the same moment can't both pass.
  • Reply: "200 OK" quickly, once the event is stored, to reduce resends.

📖 Revise: Lesson 3: Duplicates and safe repeats

Why each option is right or wrong

• “The alert email went to spam” (Incorrect): Possible in general, but here no error was raised in the first place.
• “Error workflows only work on cloud plans” (Incorrect): Error workflows work on self-hosted n8n too.
• “The tidy-up had nothing to clean those weeks” (Incorrect): The run didn't happen at all; this isn't about the data.
• “The workflow didn't run, so no error fired” is correct.

  An error workflow reacts to failed runs. When the server stops running the workflow at all, nothing fails, so nothing alerts. A health check on a separate service that expects a run each Monday catches this kind of silent failure.

  • Also add: disk space alerts on the server.
  • Weekly summary: makes a missing run obvious.

📖 Revise: Lesson 4: Run logs and health checks

Why each option is right or wrong

• “Nothing until a customer complains” (Incorrect): Customers may not complain for days, and orders could be lost meanwhile.
• “Restart the server automatically every two hours” (Incorrect): Restarting blindly may not fix the cause, such as a changed webhook setting.
• “Delete the run log and start a new one” (Incorrect): The log is the evidence; deleting it removes the clue.
• “Alert staff to check the shop and workflow” is correct.

  Two hours with no orders on a busy weekday is unusual. An alert prompts staff to check, and here the shop's webhook settings had changed. Orders that arrived meanwhile can be imported from the shop's export.

  • Schedule: hourly during shop hours only.
  • Threshold: based on normal order patterns.

📖 Revise: Lesson 4: Run logs and health checks

Why each option is right or wrong

• “Ask the former employee to keep the account open” (Incorrect): The business would depend on someone who no longer works there.
• “Copy the sheets into the employee's new account” (Incorrect): The data would still sit outside the business's control.
• “Give the new connection access to all company sheets” (Incorrect): More access than needed increases risk; two named sheets are enough.
• “A company account limited to those sheets” is correct.

  A personal account ties the business's workflows to one person. A company-owned service account keeps working when staff change, and giving it access to only the sheets it uses limits the harm if it's ever misused.

  • Record: owner and renewal date in the credentials list.
  • Test: a run after switching, before the old account closes.

📖 Revise: Lesson 5: Credentials, access and safe changes

Why each option is right or wrong

• “Edit the live workflow quickly while orders are slow” (Incorrect): During a sale, even a few minutes of broken orders cost money, and a typo can stop the flow.
• “Make the change and watch the next few orders closely” (Incorrect): Watching helps you notice a problem but doesn't prevent one.
• “Turn the workflow off while editing” (Incorrect): Orders arriving while it's off would be missed or need importing later.
• “Test on a copy; publish after the rush” is correct.

  Testing on a copy with pinned data catches mistakes without risking live orders. Saving a version first lets you go back, and publishing at a quiet time, or after the sale, limits the harm if something still goes wrong.

  • Rule: freeze big changes during sale weeks.
  • Note: what changed, when and why.

📖 Revise: Lesson 5: Credentials, access and safe changes