A useful downtime monitor for a multi-service SaaS application should answer one operational question: can we reconstruct what stopped the nightly data pipeline, in order, from signals that were captured before the alert? The decision rule is simple: treat endpoint availability as a symptom, and preserve a time-correlated record of dependency health, pipeline stages, and customer-visible impact.

Short answer: probe the externally meaningful workflow, collect shallow health signals from each dependency, attach a stable trace or run identifier to structured events, and alert on an SLO-relevant condition rather than on every failed check. A service returning 200 is not proof that a pipeline can read, transform, and publish its data.

That is the whole point.

How does downtime monitoring work across multiple SaaS services?

For a B2B SaaS nightly pipeline, the monitor has two jobs that are easy to confuse. A liveness check asks whether a process is running.…