Monitor the result, not only the error log
Business automation monitoring needs three separate checks: did a run fail, did an expected run never arrive, and did the required result reach its destination? A green execution status answers only part of that question. An error notification cannot detect a job that never started.
Start with one important recurring handoff. Write down its expected result, deadline and owner. Then test each signal below. This guide covers detection. Safe retry design is a separate task; see preventing duplicate automation actions before replaying uncertain work.
| Signal | Evidence | Next check |
|---|---|---|
| Failed run | An execution reports an error. | Find the failed step and any effects already completed. |
| Missing or late run | No expected start or completion is visible after its agreed deadline. | Check the schedule, trigger, time zone and monitoring access. |
| Missing output | A run completed, but required destination records are absent or unconfirmed. | Compare the expected record identifiers with actual destination evidence. |
Define what healthy means before building an alert
Use a small result contract. This is a written agreement about the expected business result. Include these fields:
- Window: when the workflow should run, its named time zone, and any weekends or holidays it excludes.
- Input boundary: which records belong to this run, the cutoff time and the source snapshot or batch identifier.
- Eligibility: which records need an output and which are explicitly held for review.
- Completion evidence: the destination identifiers and fields that confirm a correct result.
- Deadline: when the result must exist, plus a separate check time.
- Responsibility: who checks a problem and who can authorize recovery.
Do not call an inaccessible source an empty source. A successful query that confirms zero eligible records can be a valid result. A failed query gives an unknown result. Decide in advance whether a zero-record day is normal for this particular process.
Keep the checker separate from the work it checks
A scheduled checker can ask whether the expected run and output exist. If it depends entirely on the same stopped trigger, it may never notice the missing run. Separate the checking path where practical. Record when the checker itself last completed. This does not remove every shared dependency; document failures that could stop both paths.
Google's monitoring guidance distinguishes internal system signals from externally visible behavior. For a small business workflow, use both: execution evidence and a direct check of the result your team needs.
Fictional example: the daily request handoff
This example is fictional. A team turns approved requests into internal tasks. Its daily run is due at 09:00 America/Phoenix. The agreed result deadline is 09:10. A separate checker runs at 09:12. These times illustrate a contract; they are not performance benchmarks or universal alert thresholds.
The source query succeeds and captures 14 distinct requests before the cutoff. Two requests are explicitly held for review. The expected output set therefore contains 12 request identifiers. The destination confirms tasks for 11 of those identifiers. The final identifier has an unknown outcome after a connection interruption.
The system must not report healthy completion. It also must not assume that the uncertain task was never created. Check the destination using the same stable request identifier before retrying. An equal total count alone is insufficient: a duplicate task could conceal a missing request. Compare identifiers, the batch window and the required fields.
| Situation at the check time | Expected signal |
|---|---|
| The run records an error at 09:04. | Failed run. Inspect partial results before recovery. |
| Monitoring access works, but no expected run exists by 09:12. | Missing run. Inspect the trigger and schedule. |
| The run says completed; only 11 of 12 required identifiers are confirmed. | Output gap. Keep the uncertain identifier unresolved. |
| The source query succeeds, confirms zero eligible requests, and zero is allowed. | Valid zero-record completion. |
| The checker cannot query the source, run history or destination. | Monitoring unavailable. Do not declare the workflow healthy. |
| All 12 required identifiers and fields are confirmed exactly once, with no unexpected outputs. | Healthy result for this window. |
If you use n8n, test the automatic path
n8n supports a separate error workflow that starts with an Error Trigger. Select it in the main workflow settings. It can handle a reported execution failure; it does not replace the missing-run checker or destination check. See n8n error handling.
The Error Trigger documentation says that the trigger responds to errors in automatic executions. A manual execution alone does not test that path. Use an authorized controlled automatic trigger and synthetic records for the failure drill.
For a scheduled main workflow, verify its saved and published state and its actual time zone. The Schedule Trigger documentation explains the workflow and instance time-zone settings. Check the expected next run against your business window. A configured schedule is not evidence that a later run succeeded.
Give the owner one clear next action
An alert should identify the workflow, affected window, signal type and evidence location. Add the expected result, observed result, responsible person and safe next check. Link to restricted records rather than placing customer data or credentials in a notification.
Group repeated checks for the same incident with one incident key. Record an acknowledgement separately from recovery. Close the incident only when the required destination result is confirmed or an authorized person records a different accepted outcome. Avoid repeated notices that provide no new information.
During the drill, verify that the owner can open the evidence and distinguish a workflow failure from a monitoring failure. Choose escalation times from the impact and staffing of this process. Do not imply that every workflow needs round-the-clock support.
Copy this monitoring worksheet
WORKFLOW MONITORING CHECK Workflow / owner: Schedule / named time zone / business calendar: Input cutoff / batch identifier: Source query confirmed successful? yes / no / unknown Expected unique eligible identifiers: Held identifiers and explicit reason: Zero eligible records allowed? yes / no Expected start / result deadline / check time: Run evidence: started / completed / failed / absent / unavailable Destination evidence: confirmed IDs / missing IDs / unknown IDs Unexpected or duplicate outputs: Required destination fields checked: Checker last completed: Signal: failed run / missing run / output gap / monitoring unavailable / healthy Incident key / evidence link / owner / safe next check: Acknowledged at: Recovery evidence / accepted outcome / closed at: CONTROLLED DRILL [ ] Known automatic execution failure is detected. [ ] A missing expected run is detected without an error event. [ ] A completed run with one uncertain output stays unresolved. [ ] A confirmed permitted zero-record run stays quiet. [ ] Unavailable monitoring never becomes a healthy result. [ ] Recovery checks destination IDs before a retry. [ ] Incident closes only after the result is confirmed.
Start by filling this in for one handoff. Run the controlled drill in a test environment. Keep production recovery under the existing access and approval rules. If the team cannot define the result yet, clarify that before adding more alerts.
Turn the check into an operating routine
For help reviewing an existing workflow, see ongoing systems support. For a new monitored handoff, see workflow automation implementation. Bring a redacted example and your expected result to a free fit call. Scope and support responsibilities are agreed before work starts.