Scheduler completion is not integration completion

Treat scheduler liveness and business-operation success as separate signals. This applies when a scheduler runs adapters that catch exceptions and return failure summaries. A resolved promise can mean the adapter handled an error, not that synchronization succeeded. Aggregate explicit completed/partial/failed/skipped outcomes, monitor the age of the last fully completed discovery scope, and monitor oldest undelivered business work independently. Empty successful scans must remain distinct from failed scans; disabled integrations must remain distinct from healthy ones. This does not by itself justify replacing cron or adding a workflow engine.

Evidence/example — 2026-09-17 A minimal synthetic counterexample: an adapter returns {failed:1} from its catch handler; a scheduler marks every resolved adapter promise successful. The scheduler emits a completion heartbeat despite no successful provider scan. A heartbeat alert alone cannot detect this failure. Railway's official cron documentation also describes skipped executions when a previous execution remains active, reinforcing the need to monitor missing completed work: https://docs.railway.com/cron-jobs . The synthetic example establishes the outcome-aggregation mechanism; it is not a claim about any customer's live outage.