To monitor a scheduled job, give it an expected schedule, record when each run starts and how it ends, and alert someone when a run fails, runs long or never shows up. The missing run is the hardest case. A job that never starts throws no error, so only a check against the clock catches it. This guide covers the signals worth tracking, how to set up alerts that don't cause fatigue, and how to apply all of it to scheduled reports in Power BI, SSRS, Tableau and Crystal Reports.
TL;DR
- Track three outcomes for every job: succeeded, failed and missed. Add duration, because a run that takes too long is often the first warning.
- Use a start signal and an end signal. If the end signal never arrives within the maximum runtime, treat the run as hung.
- Alert on late or absent success, not only on errors. Tier alerts by how critical the job is so people keep reading them.
- For reports, monitor generation and delivery separately. A report that is built but never delivered has still failed from the recipient's point of view.
- Use the monitoring built into your automation tool for report jobs, and a central view when jobs span cloud and on-premises systems.
Table of Contents
- What it means to monitor a scheduled job
- The signals worth tracking
- How to set up completion checks and heartbeat alerts
- Configuring alerts that people still read
- Investigating and preventing repeat failures
- Monitoring scheduled reports: generation and delivery
- Monitoring across cloud and on-premises
- Our perspective
- Put report monitoring on autopilot
- FAQ
- Sources
What it means to monitor a scheduled job
Monitoring a scheduled job means more than reading a log after something breaks. It means knowing, at any moment, whether each job ran when it should, finished, and finished correctly. Sentry's job monitoring records successful, failed and missed check-ins, shows recent statuses and runtime trends, and can notify you about missed or failed executions.
The three outcomes are different problems:
- Successful: the job started and ended cleanly within its expected window.
- Failed: the job started and reported an error, or returned a bad result.
- Missed: the job did not execute within its predicted timeframe. In Sentry's definition, a missed check-in means the job did not run in its expected time or frequency.
Most teams only watch for the second one, because failures write to a log. Missed runs leave nothing behind. A disabled scheduler, an expired credential, a server that was patched and rebooted, or a service account that lost permissions can all stop a job silently. The first anyone hears of it is a stakeholder asking where the report is.
The signals worth tracking
You don't need dozens of metrics. A short, consistent set per job covers almost every failure pattern.
Start and end signals
The most useful pattern is a pair of signals. Sentry's check-in model uses an in-progress signal followed by an ok or error signal, which lets monitoring measure runtime and spot incomplete executions. If a run sends the first signal but never the second, you know it started and then hung or died.
Duration
Duration is a leading indicator. A job that normally takes four minutes and now takes twenty is telling you something about data volume, locks or a slow source system, often well before it fails. Cronitor documents performance assertions such as maximum and minimum duration to catch hangs, regressions and suspiciously short runs. The short-run check matters too. A job that finishes in two seconds when it usually takes ten minutes may have processed nothing.
Expected schedule and tolerance
Every job needs an expected schedule so that "late" has a definition. Sentry's check-in settings include the expected schedule, a check-in margin and a maximum runtime. The margin is your grace period, and the maximum runtime is your hang threshold. Set both from observed behavior, not guesses, or you will drown in false positives.
Native scheduler state
If your jobs live in an operating system or database scheduler, use what it already exposes:
- Windows Task Scheduler: Dynatrace's extension polls configured tasks every minute and reports each task's current state and time since its last execution. It can also ingest Windows task events as log records. Splunk's PowerShell example flags failed tasks through a nonzero LastTaskResult and missed runs through NumberOfMissedRuns.
- Oracle Scheduler: job-run and state-change data is available through the scheduler job log and run details views. Logging can be set to failed runs only, every run, or full operational activity including create, enable, disable, update, stop and drop operations.
A quick reference
| Signal | What it catches | Typical alert rule |
|---|---|---|
| Failed status or error code | Crashes, bad credentials, query errors | Alert on first failure for critical jobs |
| Missing success by deadline | Disabled schedulers, server downtime, silent skips | Alert when no success arrives within the grace margin |
| Start with no end | Hung or killed runs | Alert after maximum runtime passes |
| Duration above normal | Data growth, locking, slow sources | Warning when above your normal range |
| Duration far below normal | Empty results, early exits | Warning when under minimum duration |
| Time since last success | Everything above, as one number | Alert past the job's expected interval |
How to set up completion checks and heartbeat alerts
A heartbeat is a simple idea: the job tells the monitor it is alive, and the monitor complains when it stops hearing. Here is the sequence that works for most jobs.
- List the jobs that matter. Start with the ones that someone would notice within a day if they stopped: financial close reports, executive dashboards, customer-facing exports, data loads that feed other jobs.
- Define the expected schedule for each. Write down when it should run and by when it should finish.
- Emit a start signal when the run begins and a success or failure signal when it ends.
- Alert on late or absent success. Sentry's guidance is to treat a missing final signal after the maximum runtime as a timeout.
- Add grace and duration tolerances. Cronitor recommends tolerance settings for consecutive failures, missed schedules and late starts, so one slow run does not page anyone at 3 a.m.
- Route the alert to someone who can act, with the job name, expected time, last successful run and a link to the logs.
Test the alerting itself once. Disable a non-critical job on purpose and confirm the right person hears about it. A monitor that has never fired is an assumption, not a control.
Configuring alerts that people still read
Alert fatigue kills monitoring faster than any technical gap. Three habits keep alerts useful.
Tier by criticality. Power BI Consulting suggests categorizing datasets by criticality, alerting immediately for the top tier and sending a daily digest for the lowest. The same logic applies to any job. A board report deserves a page. A weekly archive export deserves a line in a morning summary.
Put the diagnosis in the alert. The same guide recommends including the name, workspace, error message, last successful refresh time and owner in every alert. A notice that only says "job failed" sends the recipient hunting.
Let the platform detect what it can. Dynatrace opens problems for listed failure events, over-time tasks and missed runs, based on each task's timeout and execution frequency, which you can auto-detect or set manually. Fewer hand-built rules means fewer rules to maintain.
Investigating and preventing repeat failures
An alert tells you something broke. Logs tell you why. When a job fails or stops, go to the scheduler's own run history first. In Oracle's case that means correlating log and run-detail rows and inspecting actual start times and durations against the plan.
Then look for patterns across weeks, not single runs:
- Same time, same failure. Often a competing job, a maintenance window or a credential that expires on a cycle.
- Gradually rising duration. Data growth, a missing index or a slow source. Fix before it crosses the timeout.
- Fails on schedule but works manually. Usually an environment difference: the account the scheduler uses, permissions, mapped drives or drivers. Our own write-up on Crystal Reports that work manually but fail when scheduled walks through this class of problem.
- Several jobs fail together. Look upstream at a shared database, gateway, mail server or network path.
Keep a short incident note for each recurring failure: cause, fix, and the check that would have caught it sooner. After a few months, that list is your monitoring roadmap.
Monitoring scheduled reports: generation and delivery
Report automation adds a twist. A report job has two stages, and either can fail without the other noticing. Cron Crew makes the point plainly: monitor the generation job and the delivery job separately, track duration as a leading indicator, and configure alert channels for each. A report that generates but never sends is still a failure for the person waiting for it.
In practice, ask four questions for every recurring report:
- Did the data refresh finish before the report ran?
- Did the report render and export, to PDF, Excel or another format?
- Did the delivery reach every destination: email, file share, cloud storage, collaboration tool?
- Did the run finish within its normal time?
Power BI and SSRS
For Power BI refreshes, built-in failure emails go to the dataset owner only. MetricSign describes four approaches to refresh alerting: those emails, API polling with a script, Azure Monitor rules for Premium or PPU workspaces with Log Analytics, and dedicated monitoring tools.
For on-premises gateways, Power BI Consulting lists gateway service status, P90 query duration, concurrent queries, memory, failed queries, disk space and certificate expiration as the things to watch, split into critical and warning tiers.
SSRS and Power BI Report Server administrators often query the ReportServer database directly. Martin Guth shows a paginated report built on that data with last run status, next run time and last run time, plus a query that lists reports with errors or overdue runs. That works, but you build and maintain it yourself.
Tableau and Crystal Reports
Tableau and Crystal Reports bring their own scheduling quirks and fewer native views of what happened after a send. The practical rule is the same: you need a record per run, a view of what is running now, and a way to rerun what failed. Our guide to monitoring Tableau report batches and recovering failed deliveries covers the recovery side for Tableau.
What this looks like inside our tools
We built monitoring into the products so report teams don't have to assemble it. Our knowledge base documents each piece:
- PBRS: the PBRS web application dashboard and the PBRS System Monitor.
- ATRS: the ATRS dashboard in the web application and the history view across multiple ATRS schedules.
- CRD: a live view of running schedules, the history view across multiple CRD schedules, and a page on how to monitor CRD API schedule executions.
- Capacity: a page on viewing current system usage, including maximum daily outputs and peak usage.
Monitoring across cloud and on-premises
Many teams run a Power BI service in the cloud, an on-premises gateway, SSRS on a local server and a Tableau deployment somewhere else. Each has its own scheduler and its own idea of a failure.
ManageEngine notes that separate monitoring tools for each environment can create visibility gaps, disconnected alerts and extra troubleshooting effort. Its guidance also warns that one threshold rarely fits both: on-premises and cloud workloads have different usage patterns, and auto-scaling cloud instances make baselines move. Use environment-specific baselines, and send every alert to one place with the same fields.
Our perspective
Most of the monitoring problems we see are not technical. They come from a reporting process that depends on people noticing.
A native subscription sends a report and, if it fails, a message goes to one owner who may be on vacation. Meanwhile, the finance director is waiting on a file that never arrives. The fix is not another script. It is a reporting layer that treats generation, formatting and delivery as one managed workflow, with a record of every run.
That is how we designed PBRS, ATRS and CRD. They schedule, export and deliver Power BI, SSRS, Tableau and Crystal Reports content, with built-in error handling and dashboards and histories that show what ran, what is running and what failed. Teams that outgrow native scheduling get one place to look instead of five.
Our advice: monitor the report job the way you monitor a production system. Name an owner, define the deadline, watch duration, and make sure a failure reaches a person who can act on it.
Christian Ofori-Boateng
Put report monitoring on autopilot
If the scheduled jobs you worry about are BI reports, our software handles scheduling, export, delivery and run visibility in one product. PBRS covers Power BI and SSRS, ATRS covers Tableau, CRD covers Crystal Reports, and IntelliFront BI centralizes dashboards and KPIs. It is available as a subscription or perpetual license, and you can start from the ChristianSteven product page.
If you work mainly in Power BI, the PBRS Power BI report scheduler page shows how scheduled exports work. Tableau teams can start with the ATRS Tableau report scheduler, and Crystal Reports teams with the Crystal Reports scheduler.
FAQ
What is the difference between a failed job and a missed job?
A failed job started and ended with an error. A missed job never ran in its expected window, so it produced no error at all. Missed runs need a schedule-aware check, such as an alert when no success arrives by a deadline.
How do I know if a scheduled job is hung?
Compare the start signal with the end signal. If a run starts but sends no completion within its maximum runtime, treat it as hung. Set the maximum from observed durations, with some headroom, so normal variation doesn't trigger it.
Should I alert on every failure?
Only for critical jobs. Tier your jobs: page immediately for the ones with hard deadlines, and send a daily digest for low-priority ones. Include the job name, error and last successful run in each alert so the recipient can act without digging.
Why monitor report generation and delivery separately?
They fail for different reasons. Generation fails on data, queries and rendering. Delivery fails on mail servers, permissions and destinations. Watching them separately tells you where to look first, and a generated but undelivered report still counts as a failure to the recipient.
Sources
- Sentry: Job Monitoring
- Sentry: Check-Ins
- Dynatrace: Windows scheduled tasks extension
- Splunk: Monitoring Scheduled Tasks with PowerShell
- Oracle: Monitoring Jobs
- Cronitor: Cron Job Monitoring
- Cron Crew: Monitoring Scheduled Reports and Exports
- MetricSign: Set Up Power BI Dataset Refresh Alerts
- Power BI Consulting: Power BI Monitoring and Alerting Setup Guide
- Martin Guth: Monitoring Power BI Report Server Execution Status
- ManageEngine: How to monitor hybrid servers from one console