Scheduled Report Operation and Limitations

Report Generation Behavior

Understanding how scheduled PDF reports are generated can help you design reports that run reliably.

Widget Execution.  Widgets are rendered in parallel during scheduled PDF report generation, not sequentially. This means multiple widgets can load simultaneously, which improves report generation performance.

Caching Behavior.  Scheduled PDF report generation uses cached results when available, following standard cache validation rules. If a widget's query results are already cached, the report uses those results instead of running the query again.

Timeouts.  Scheduled PDF Reports have a 30-minute timeout in SaaS environments. For self-hosted deployments, the timeout can be configured if needed. If report generation takes longer than the configured timeout, the report will fail.

Performance Recommendations.  For reliable scheduled reports, design dashboards that load quickly. If a dashboard takes hours to load interactively, it will not work well for scheduled PDF reports. Consider optimizing queries or reducing the number of widgets before scheduling reports.

Report Limitations

Current limitations of Scheduled Reports are:

  • Each report can be set to a maximum once per hour frequency.

  • There is a limit of 20 reports per repository or view.

  • Email attachments are limited to 5MB.

  • Table and Event List widgets can output a maximum of 1,000 rows.

  • The PDF report does not automatically handle or solve for reports or dashboard layouts that are wider than the available PDF report width. The report system does not support an arbitrary number of columns and rows.

    Use the layout preview functionality you can see how it will look, and the red borders indicate that something is going out of bounds.

    The dashboard can then be adjusted accordingly to fit the size of the PDF report, or alternatively if the dashboard is used for other purposes as well then create a copy with the needed changes.