A scheduled report is easy. A scheduled report that refuses to send bad numbers, and an alert that a person actually reads, are the useful parts.
A job that runs on a schedule or on an event, checks its own inputs and outputs, and either completes quietly or tells a person exactly what went wrong. The month-end report that someone builds by hand on the first Monday; the list that gets reconciled in a spreadsheet; the approval that lives in an inbox. Each becomes a job with a gate, an owner and an alert.
A set of checks that run after the pipeline and before anything is sent: row counts within range, no dates in the future, totals that reconcile to the source, no duplicate keys. If the checks pass, the report refreshes and goes out. If one fails, nobody gets a report; the flow posts the failing check with the query that reproduces it and opens a ticket. A report that is late is a nuisance. A report that is wrong costs credibility you do not get back.
Power Automate for the last mile inside Microsoft 365: sending the approved report, posting to a Teams channel, collecting an approval, filing to SharePoint. Python for anything with logic, data or volume: the checks, the reconciliation, the API calls, the retries. The usual shape is a Python job that does the work and a short Power Automate flow that delivers it, each doing the part it is good at.
It reaches a person, not a dashboard nobody opens. It carries a link to the failing run, not just the words "job failed". It says what to do, by linking the runbook. It fires once per incident, not once per minute. And it is quiet when nothing is wrong, because an alert channel full of noise is an alert channel nobody reads.
One page per alert: what the alert means, how to confirm it, the three most likely causes with the query or command that checks each, what to do, and whom to tell. Written during the build, tested by breaking things on purpose before launch, and handed over with the system. It is what lets someone who did not build the system fix it at 3 am.
Four things on one page. Freshness: when each table and each report last updated, against when it should have. Quality: how many rows failed each rule in each run. Cost: what the platform and the AI calls spent today, this week, against the ceiling. Usage: who used what, so you know whether the thing is being used at all. Plus the health of the jobs themselves: last run, duration, failures.
A slow change in the data or in an AI system's behaviour that no single run would flag: a source that starts sending 10% fewer rows, a category that quietly disappears, a model whose refusal rate doubles after a prompt change. Drift checks compare each run with a rolling baseline and alert on the trend, not the single value, so the slow failures get caught before someone notices in a quarterly review.
Mostly what you already own. Databricks jobs and system tables for pipelines; Azure Monitor and Log Analytics where the platform is Azure; scheduled SQL for quality and drift checks; Power BI for the dashboards; Teams or email for alerts; the audit and trace tables we build for AI systems. A dedicated observability product is added only when the volume or the team justifies it.
Because we break things on purpose before launch: delete a source file, send a malformed row, push a cost over the ceiling, make a model refuse everything. Each break must produce the right alert with the right link within the agreed time, and the runbook must lead to the fix. A monitoring system that has never fired is an untested one.
Tell us what it is and how often. We reply within a working day with how it would run on its own.
