Monitor business outcomes—not only uptime
A workflow can be technically online while producing stale records, growing an exception queue or failing to deliver useful outputs. Monitor whether the expected business result completed within the required time.
Define a small set of signals around volume, completion, delay, exceptions and downstream acceptance. Compare them with the baseline and the normal operating range.
Runs started
Expected versus actual workflow volume by source and period.
Runs completed
Items reaching the defined business outcome without unresolved failure.
Cycle time
Elapsed time from trigger to useful output, including review waits.
Exception health
Rate, age and category of items that leave the standard path.
Make alerts actionable
An alert should tell the owner what failed, which items are affected, whether the impact is contained and what action is available. Avoid sending every technical warning to business users.
Set urgency from consequence and backlog growth. One delayed internal summary may wait for business hours; a customer-facing duplicate action may require immediate containment.
Signal
Define the observable condition that indicates business impact.
Severity
Connect urgency to consequence, affected volume and recoverability.
Owner
Assign the person or team responsible for the first response.
Runbook
Provide containment, diagnosis, retry and escalation instructions.
Design recovery before a failure
Preserve the original input and each completed step so the workflow can resume without repeating side effects. When automatic retry is safe, limit and record it. When it is not, create an explicit manual recovery action.
Practice recovery using test failures before launch. Confirm that the team can find affected items, restore service and verify the final business result.
Contain
Stop uncertain downstream actions and keep affected items visible.
Diagnose
Separate bad input, business-rule conflict, dependency failure and system defect.
Resume
Continue from the last safe point without duplicating completed actions.
Verify
Confirm the intended record, message or handoff exists after recovery.
Control changes to rules, systems and models
Business rules, source formats, integrations and AI behaviour change. Record dependencies and assign an owner who can approve updates. Test changes against representative normal and exceptional cases before production.
Use operating evidence to decide improvements. A recurring exception may justify a new rule; a rarely used branch may not. Maintenance should protect the business outcome rather than preserve the original implementation.
Change log
Record what changed, why, who approved it and the effective date.
Regression set
Retest representative normal, boundary and exceptional cases.
Rollback
Keep a safe way to restore the last dependable configuration.
Review cadence
Review volume, failures, exceptions and control performance on an agreed schedule.