Most reporting infrastructures look like this: the ADC or WAAP product generates periodic PDFs, drops them into a file share, and a weekly cron or manual step emails them to the right stakeholders. There are multiple manual links in the chain; if any one breaks, the missing stakeholder may be out of the loop for weeks.
Beyond that, different stakeholders inside the same organization need the same vService's report at different depths. The board wants a two-page monthly summary; operations want a weekly full view; internal audit wants a daily full XLSX. A single report profile can't serve all three — but most products only allow one profile per vService.
High-availability clusters introduce another trap: if the same scheduled report is generated from multiple nodes, the stakeholder either gets two copies of the same PDF or the operator writes coordination scripts. Cluster-aware single-send semantics are usually outside the software and on the operator's shoulders.
Format and language preference are problems too. In service-provider scenarios, each customer should receive a report in their own language, with their own logo. Common products may not allow per-profile language preference; a single global setting governs every report.
TR7 Scheduled Report Delivery solves all four in one product: multi-frequency + multi-recipient + multi-format per profile, unlimited profiles per vService, cluster-aware single-send, per-profile language preference.
TR7 designs report scheduling as a natural part of the vService configuration — no separate scheduling service, no separate UI, the profile lives under the vService.
Hourly, daily, weekly, monthly and annual presets are bound to fixed cron expressions. The ad-hoc form and the scheduled profile share the same parameter set — the operator fills the form once, saves as a profile, chooses a frequency, and delivery starts.
Each report profile can be assigned to multiple email recipients, multiple file types (PDF, XLSX) and multiple frequencies. One profile can deliver a weekly PDF summary and a monthly full XLSX to different stakeholder sets in parallel.
A vService can carry one primary profile and any number of additional profiles. Monthly executive summary, weekly operations detail, daily full-coverage audit PDF — all under the same vService, from the same data source.
In a high-availability cluster, the same scheduled report is generated and sent only by the active node. Operators don't need to write coordination scripts to prevent double delivery; the engine knows the cluster topology.
The scheduling surface — profile definition, frequency selection, recipient management, file type and language preference — runs on a shared ad-hoc + cron engine.
Hourly: each hour + 5 minutes. Daily: 01:30. Weekly: Monday 03:30. Monthly: 1st of month 05:30. Annual: turn of the year. A single profile can be assigned to multiple frequencies; the same dimension set can ship to different recipient sets on different schedules.
Profiles are defined by name under each vService ("Executive Monthly", "SRE Weekly", "Internal Audit Daily"). Profile names appear in the operator console, in email subjects and in audit logs — making it traceable who received what report under which profile.
Each profile can ship to multiple email addresses. Addresses are validated against the email pattern on save; invalid addresses are rejected. The ad-hoc report form also accepts a one-off recipient.
The same scheduled report can render as both PDF and XLSX and attach to the same email. Stakeholders get two views of the same data — PDF for reading, XLSX for detail querying.
Every report profile specifies its own language. In service-provider scenarios each customer receives the report in their own language; the same engine produces parallel reports in different languages for tens of customers. Cover-page titles and section labels localize to the profile's language.
In a high-availability cluster, a given scheduled report is generated and sent only once, from the active node. Operators don't write coordination scripts, stakeholders don't get duplicate PDFs, and inter-node races don't happen. The engine knows the cluster topology and behaves accordingly.
Every vService can carry one primary report profile and any number of extra profiles. The primary profile lives in the vService config; extras are managed in a separate list. Different stakeholders receive different report depths under the same vService.
The operator-console ad-hoc report form (format, range, dimensions, chart selection, row cap, language, target email) shares the parameter set 1:1 with the scheduled profile. A satisfactory ad-hoc output becomes a profile and starts running on cron.
The scheduling engine is designed alongside cron expressions, file lifecycle, email delivery, cluster behaviour and audit logs.
Hourly 5 * * * *, daily 30 1 * * *, weekly 30 3 * * 1, monthly 30 5 1 * *. The same scheduled-report slots are positioned to avoid overlap with other periodic jobs; hourly reporting doesn't land at any single traffic peak.
PDF / XLSX attachments are delivered as standard SMTP email; the subject line is configurable. The engine works through corporate email servers (Exchange, Postfix, supervised cloud providers). Webhook, S3 upload and SFTP delivery are not in the current release.
Generated report files are written under /tmp with timestamped names, used as email attachments, and removed by the OS lifecycle. Long-term archive requires manually forwarding the profile output to a shared store, or configuring SIEM forwarding.
Only the cluster's active node performs periodic delivery; standby nodes do not execute the same cron. On failover, the new active node assumes delivery from the next period onward.
Both L7 traffic reports and WAAP attack reports run on the same scheduling engine. Operators don't manage two scheduling services; profile definitions, frequency presets and recipient management are identical for both surfaces.
When a profile is updated, the changes apply on the next cron trigger; running generations are unaffected. When a profile is deleted, future triggers are cancelled while historical delivery records are preserved.
Banks and conglomerates ship a monthly executive PDF per vService to the board — cover page with corporate logo, 2-3 pages of total traffic, geographic intensity, error rate and backend health. The profile assigns to monthly frequency with multiple recipients in parallel.
SRE teams receive a weekly full-breakdown XLSX for the same vService — one tab per section, ready for detail analysis. "Executive Monthly" and "SRE Weekly" profiles run in parallel under the same vService.
Internal audit receives daily full-coverage reports — PDF and XLSX together. Daily PCI DSS dossier entries accumulate automatically; the auditor's archive is single-source at month end.
MSPs define a per-tenant report profile under each vService; each customer receives a monthly report in their own language, with their own logo, to their own email list. No manual step; onboarding a new tenant is a new vService + profile away.
5 frequency presets, multi-recipient, multi-format, cluster-aware single-send, per-profile language preference. Let us walk you through a live demo on your own vService.