How the problem develops
A connection expires or a field changes, and routine updates stop arriving. The last report still looks healthy because it contains old values. Nobody owns the difference between a workflow that succeeded and one that never ran.
What to check first
- Identify the last successful run, its source timestamp and the expected next run.
- Check for missing triggers as well as explicit errors; silence is not evidence of success.
A better process
- Define what a successful run means, including the expected output.
- Track failures, missing runs and stale data separately.
- Assign an alert owner and document how to retry or recover without duplicating actions.
What a system can do
Check the agreed run schedule and output freshness, then raise a bounded alert with a safe reference to the failure.
Where people stay in control
Do not include unnecessary client content in alerts or retry irreversible actions without a reviewed recovery rule.
Benefits and tradeoffs
The useful outcome
An interruption becomes visible before staff mistake stale information for current work.
The tradeoff
Noisy alerts are easy to ignore. Group repeated failures and distinguish issues that require action from routine notices.
Test before going live
Disable a trigger, expire a test connection and repeat a failed job. Confirm detection, ownership and recovery without duplicate customer messages.