A scheduled report is the difference between data that sits in a historian and information that lands in the right person's inbox every morning without anyone lifting a finger. Plenty of sites build a nice report template, run it by hand when someone asks, and then let it languish because manual reporting always loses to more urgent work. Scheduling turns that template into a standing deliverable, a daily production summary, a shift log, an end-of-month totals sheet, that arrives on time whether or not anyone remembers to ask for it. This guide covers the second half of the reporting job, the part that takes a template you already have and makes it run itself: mapping the template to the right tags and time range, choosing an output format people can actually use, setting a schedule that matches the business rhythm, and delivering it to the people who need it.
How to set up a scheduled report in one line: To set up a scheduled report in SCADA, start from a report template, map its fields to the tags and the time range it should cover, and choose an output format, PDF for a fixed human-readable document or CSV for data someone will analyze further. Then set the schedule so it runs on the cadence you need, daily, per shift, weekly, or monthly, with the report window aligned to that period, and add the email recipients or the file destination where it should be delivered. Finally, let one cycle run and check the delivered report to confirm the numbers, timing, and recipients are all correct before you rely on it.
A report template defines the layout and the calculations, the header, the columns, the totals and averages, but it is deliberately generic so it can be reused. Scheduling starts by binding that template to specifics. The most important binding is the set of tags the report draws from, so a daily production report template gets pointed at this site's flow totalizer, this tank's level, this meter's volume. The second binding is the time range, and it is more subtle than it looks, because a scheduled report's range is usually relative rather than fixed: the report should cover the previous day, or the last shift, or the past calendar month, so that each run automatically covers the right window without anyone editing dates.
Getting the relative time range right is where scheduled reports most often go wrong. A daily report that runs at midnight should summarize the day that just ended, not the day about to begin, so its window has to be defined as the previous twenty-four hours or the previous calendar day, and it has to respect the site's time zone and any shift boundaries. A monthly totals report has to cover the calendar month that closed, not a rolling thirty days, if the numbers are meant to reconcile with accounting. Thinking through exactly which period each run should cover, and how that period is defined relative to when the report fires, is the parameter work that makes the totals trustworthy month after month.
The output format decides who can use the report and how. A PDF is the right choice when the report is a document meant to be read, filed, or handed to a regulator or a manager: the layout is fixed, it looks the same everywhere, and nobody can accidentally alter a number. A CSV or spreadsheet output is the right choice when the recipient is going to do something further with the data, load it into their own analysis, reconcile it against another system, or pivot it themselves, because a CSV preserves the raw values in a form software can read. Some reports warrant both, a PDF for the record and a CSV for the analysts, and choosing deliberately based on what the recipient actually does with it saves a lot of downstream reformatting.
The schedule is the heart of a scheduled report, and the right cadence follows the rhythm of the operation it serves. A daily report typically fires once in the early morning so a summary of yesterday is waiting when people arrive. A shift report fires at each shift change so the outgoing crew hands the incoming one a clean picture. A weekly or monthly report fires after its period closes for reconciliation and management review. The key is that the schedule and the report's time range have to agree: a report scheduled daily at 6 a.m. covering the previous calendar day is coherent, while a daily schedule paired with a monthly window would deliver the same month-to-date figure every morning, which is rarely what anyone wants.
You also have to decide what happens if a run cannot complete cleanly, which is easy to overlook until it bites. If the system was down, a source tag was reading bad quality, or the historian had a gap during the report period, the report should ideally flag that rather than silently present incomplete numbers as if they were whole. A totals report that quietly omits an hour of missing data looks fine and reconciles wrong, which erodes trust in every report from then on. Building in a note or a data-completeness indication, and confirming how the tool behaves when a source is unavailable, is part of making a scheduled report dependable rather than merely automatic.
Delivery is the last binding, and it is what closes the loop from data to the people who act on it. Email is the most common channel: you add the recipient addresses, sometimes a distribution list, and the report arrives as an attachment on schedule. Other reports are delivered to a shared network folder, a document system, or an FTP destination for another system to pick up. Whatever the channel, the recipients should be the people who genuinely use the report, because reports sent to a list nobody reads are just clutter, and the ones who do need it should not have to go fetch it. Getting the recipient list right, and keeping it current as roles change, is a small ongoing task that keeps the reporting useful.
A scheduled report is not finished when you save the schedule; it is finished when you have watched at least one real cycle run and checked what actually got delivered. You want to open the delivered file and confirm the numbers are right for the period, the time range covered exactly what it should have, the format is what you intended, and it reached every intended recipient. This first check catches the common mistakes, a time zone that shifted the window by an hour, a tag mapped to the wrong point, a recipient address with a typo, while they are still easy to fix and before anyone has started depending on the report being correct.
Once it is running, a scheduled report's value depends on it running reliably and unattended, which is where a robust platform matters. In a cloud SCADA platform such as Merobix, reports run on the hosted system rather than on a workstation someone might turn off, so a daily production report keeps arriving even over a holiday weekend when nobody is in the office to click a button. Because the platform is already aggregating data from every site into one place, a single scheduled report can span a whole fleet, a morning summary that totals production across a dozen remote wells or stations, without anyone logging into each site to pull its numbers. That fleet-wide, hands-off delivery is exactly what scheduling is for.
Reporting across remote and unmanned sites is where scheduled reports pay off most, because the alternative is untenable: nobody is going to drive to a dozen distant sites each morning to read a totalizer and type it into a spreadsheet. A scheduled report pulls those numbers automatically from the data the sites already send in, assembles them into the daily or monthly document the business needs, and delivers it, which turns a fleet of far-flung sites into something as easy to report on as a single plant. The template and the parameters you set up once then keep producing correct, on-time reports for the life of the operation, which is the whole point of moving from running reports by hand to scheduling them.
Define the report's time range relative to when it runs rather than as fixed dates, so a report firing early in the morning is configured to cover the previous calendar day. The window has to respect the site's time zone and any shift boundaries so the totals line up correctly. Getting this relative range right is what lets the same schedule produce a correct report every day without anyone editing dates, and it is the setting people most often get slightly wrong.
Choose PDF when the report is a document meant to be read, filed, or handed to a manager or regulator, because the layout is fixed and the numbers cannot be accidentally altered. Choose CSV or spreadsheet output when the recipient will analyze the data further or reconcile it against another system, because it preserves raw values that software can read. Some reports warrant both, a PDF for the record and a CSV for the analysts, so you match the format to what the recipient actually does with it.
It depends on how the tool is configured, and this is worth checking before you rely on the report. If the system was down or a source tag read bad quality during the report period, the report can either silently present incomplete numbers as if they were whole or flag the gap. Silent omission is dangerous because a totals report that drops an hour looks fine and reconciles wrong, so building in a data-completeness indication keeps the report trustworthy.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.