Knowing a scheduled report failed

A report nobody receives looks exactly like a report with nothing to say, and that sentence is the whole reason this lesson exists. The receiving end sees no file. There are two explanations — the job failed, or there genuinely were no transactions — and from outside they are indistinguishable. The default assumption is always the second, which is why a broken nightly extract is typically discovered a week later. THE CHECK THAT DISTINGUISHES THEM IS A ZERO-ROW FILE. Deliver something every run, even when there is nothing to send: a header, a count, a timestamp. Then absence means failure, unambiguously, and the receiving system can alert on it without knowing anything about Fusion. That single design decision converts a silent failure into a detectable one and costs nothing. Configure a failure notification to a MONITORED mailbox — a shared one, not a person who may be on leave —…

In this module: Module 6 · Reports at scale: scheduling, delivery, performance

1. 1The scheduler, and what a job really is
2. 2Scheduling patterns that survive
3. 3Delivery: email, FTP and content server
4. 4Knowing a scheduled report failed
5. 5Volume: when the extract stops fitting
6. 6Incremental extracts and high-water marks
7. 7What breaks: the 2am report
8. 8Lab briefing · Schedule, deliver, and prove it ran