Scheduled PDF reports from Grafana dashboards

Scheduled PDF reports from Grafana dashboards: when teams need them

Grafana Enterprise reporting generates PDF reports from any dashboard and can schedule them to be emailed to recipients, while the open-source edition offers PDF export through the Grafana Image Renderer rather than a scheduled report feature. That difference is the starting point for this decision. A team that must send dashboard snapshots to executives, auditors or customers on a fixed rhythm needs a delivery mechanism, not only a working dashboard. Operations leads often ask for a weekly capacity summary for management, compliance teams want dated evidence of monitoring for an assessment file, and account or service managers want a monthly view of service levels for customers. Each of these requests names a recipient, a cadence and a retention expectation, and none of them is answered by the dashboard alone.

Treat reporting as its own decision because it adds components and obligations that a dashboard does not. The dashboard may already be correct and well permissioned, yet the report still depends on who owns the schedule, which mailbox or distribution list receives the file, whether recipients hold Grafana accounts, and where the generated PDFs are kept. Ask your team to write down the report recipients, the required frequency, the data sensitivity of each panel, and whether a PDF is the required format or only a convenient one. Confirm with Grafana Labs whether the scheduling and email behavior you need is included in the edition you are considering, because the answer determines whether you build around the open-source renderer or buy Enterprise.

Enterprise reporting or open-source exports: which path fits

Grafana Enterprise generates PDF reports from any dashboard and can schedule them to be emailed to recipients, so reporting arrives as a built-in feature you configure in the product. The Grafana Enterprise docs describe this capability, and that is the starting point for any scope discussion.

What it requires: an Enterprise license for the instance that produces the reports, plus outbound mail configuration so scheduled emails can leave your network.
Who operates it: the platform team keeps the instance running, while report owners set up schedules for the dashboards they care about.
Scope of the feature: the documented capability covers PDF generation and scheduled email; confirm output formats, recipient controls and retention against the current docs before you commit.
Upgrade exposure: Grafana 11.0 removed deprecated reporting API endpoints and fields, so teams that generated reports through the API had to move to current endpoints.
Cost pattern: the license is a recurring commercial cost set through a quote, and it covers the feature set rather than a single report.

Check whether your recipient, scheduling and audit needs fit the built-in feature before assuming a custom build is necessary.

Reporting options and when each fits

This table compares the four ways to get dashboard output out of Grafana, with the situation each one suits, the edition or component it needs and its main trade-off. Read it as a shortlist: the first column tells you the route, and the last two columns tell you what it costs you to run it. Confirm current scheduling and export capabilities for your exact version before you commit.

Option	Best fit	Edition or component needed	Main trade-off
Enterprise scheduled PDF reports	Recurring PDF reports from any dashboard emailed to named recipients, with minimal custom build	Grafana Enterprise, which Grafana Labs offers as a non-AGPL commercial option	Requires an Enterprise license for reporting alone, so the licensing cost must be weighed against the feature
Open-source PDF or PNG export via the image renderer	Ad hoc or automated image and PDF output where you can run an extra service and tolerate manual or scripted scheduling	Open-source Grafana plus a separately deployed Grafana Image Renderer	You operate the renderer, its sizing and its authentication, and you must confirm how scheduling is handled in your version
CSV export of panel data	Teams that need raw query results for spreadsheet analysis rather than a visual report	Available from panels in the Grafana interface; confirm the export options for your version and data source	Exports reflect the query at the time of export, with no layout, and large result sets may need limits
Externally scheduled job	Organizations that already run a job scheduler and want the report logic outside Grafana	Open-source Grafana with its HTTP API and a rendering path such as the image renderer	You own the scheduling, retries, credentials and recipient lists, and the job must track Grafana API changes between versions
Shared dashboard link or snapshot	Quick review by people who already have access, without scheduled delivery	Built-in Grafana features; snapshots may use an external endpoint unless changed	Not a report: recipients need access or the snapshot must be checked for data leakage

How the image renderer produces PDFs in the open-source edition

In the open-source edition, a PDF export is not produced by Grafana alone. Grafana hands the dashboard to a separate image rendering service that loads the dashboard in a headless browser, draws each panel and returns the result, which Grafana then assembles into a PDF or PNG. The renderer runs as its own process, usually on its own host or container, so a report request depends on two services being reachable, healthy and able to talk to each other. Before you schedule anything, confirm which renderer version your Grafana release expects, because the renderer and Grafana are configured together and the interface between them has changed across releases.

Where the renderer sits and what it is allowed to do shape reliability more than any single setting. Grafana must be able to reach the renderer over the network, and the renderer must be able to reach Grafana back to load the dashboard URL it is asked to draw, so the placement decision includes how each side resolves the other's address behind proxies, load balancers and container networks. Authentication between the two is also part of the design: the renderer call must carry a credential that Grafana trusts, and that credential becomes one more secret to store, rotate and restrict. Confirm with your Grafana version's documentation how the token is configured on both sides before you go further.

Rendering is resource-heavy and runs in a browser, so its CPU, memory and concurrency limits decide whether a batch of scheduled reports finishes or fails part way through. A large dashboard with many panels, a long time range or a slow data source can time out or exhaust memory on an undersized host. Plan the renderer's capacity against the largest dashboard you intend to export and the number of reports that may fire at the same moment, and test that combination before relying on it. The Grafana image renderer documentation is the next read for the setup details, and the dedicated image rendering service page covers sizing and Docker deployment.

Setting up PDF reporting step by step

This sequence takes a shared Grafana instance from an edition decision to a verified PDF report that reaches the right recipients. Each step ends with a check so you know whether to continue or fix the step before moving on.

Confirm edition and report requirements
Before installing anything, the platform owner and the report requester agree on what must be produced: which dashboards, what format (PDF or PNG from open source, or scheduled PDF email from Grafana Enterprise), how often, and who receives them. Grafana Enterprise includes scheduled PDF reports emailed to recipients, while the open-source edition relies on the image renderer for exports. Confirm the license terms and the features your chosen edition includes against the Grafana licensing page and your own requirements. Done means you have a written list of reports, recipients and edition, approved by the team that will run the instance.
Deploy Grafana on a supported install path
The platform team installs Grafana using a supported method such as a Linux package, a container image or a Helm chart, and points it at MySQL or PostgreSQL rather than the default SQLite, which the installation docs say is not suited to production. Record the Grafana version, since reporting behavior has changed across major releases, including the removal of deprecated reporting API endpoints in Grafana 11.0. Check that you can sign in, open a dashboard and see the server version on the administration page. The step is complete when a representative dashboard renders in the browser under the production database configuration.
Deploy the image renderer with token authentication
For open-source exports, install the Grafana Image Renderer as a separate service on a host Grafana can reach, and configure a shared authentication token so only your Grafana instance can request renders. Keep the renderer on a private network segment, not exposed to users. Set the renderer endpoint in the Grafana configuration and restart the service. Confirm the renderer version against the current Grafana release notes and your own sizing needs, since rendering large dashboards consumes memory and CPU. The step is complete when Grafana can produce a PNG of a test panel through the renderer and the renderer logs show authenticated requests only.
Configure SMTP for email delivery
The mail administrator provides an SMTP relay that accepts messages from the Grafana server, along with a sending address, credentials and TLS requirements. Enter these in the Grafana SMTP configuration, keeping the password in a secret store or environment variable rather than in plain configuration files where your policy requires it. Send a plain test message from Grafana to an internal mailbox to confirm delivery and check the headers for the sender address. The step is complete when the test message arrives in the mailbox, is not blocked by spam filtering, and the relay logs show the send succeeded.
Create a test report from a representative dashboard
Choose a dashboard that reflects production complexity, including template variables, several data sources and panels with long time ranges. Generate a PDF from the dashboard in the Grafana interface, or through the report scheduling feature if you run Enterprise, using a time range and variable values that match what recipients will need. Record how long the render takes and whether any panel is empty or truncated. If the dashboard uses a data source with restricted access, confirm the report generator's account can read it. The step is complete when the PDF shows every intended panel with correct data for the chosen time range.
Verify output and recipient access
Open the PDF on a machine outside the Grafana server and compare its panels, legends and timestamps with the live dashboard. Then confirm that each intended recipient can receive the report and that the report contains no data they are not authorized to see, since a PDF carries the data it was rendered with. Check that the recipient list and sending schedule are documented and that the owner of the report knows where to change them. The step is complete when a recipient outside the platform team confirms they received a correct, readable report and the access check matches the written requirements from step one.

Security and operational risks in shared report delivery

Scheduled reports move dashboard data out of the place where access controls apply, into PDFs, inboxes and a rendering service. The cards below cover the exposure points that appear once reports leave Grafana, and what to confirm for your version before you enable delivery. Specifics vary by release, so check the hardening guidance against your own build.

Data beyond intended recipients

A PDF is a static copy. Once it is generated, Grafana's folder and dashboard permissions no longer decide who sees it, so anyone on the distribution list or who receives a forwarded copy sees every panel rendered at that moment. Panels that use broad data source queries, template variables or annotations can carry more detail than the audience was meant to see. Before scheduling, review each dashboard as a recipient would see it, and confirm which recipients should receive which dashboards.

Renderer access and token handling

Report generation depends on a rendering service that loads dashboards on Grafana's behalf. The connection between Grafana and the renderer needs its own authentication, and the token used for it is a credential that must be stored, rotated and kept off shared hosts. Confirm which network paths can reach the renderer, that it is not exposed beyond the Grafana server, and how the current release handles renderer authentication.

Mail relay exposure

Scheduled delivery sends report attachments through an SMTP relay, so the relay becomes part of the data path. Check whether the relay accepts unauthenticated submission from the Grafana host, which recipient domains it allows, and whether attachments are logged or retained by mail gateways. Confirm the TLS settings Grafana uses to reach the relay, and treat report mail as sensitive data for retention and eDiscovery purposes.

Schedules that outlive their owners

A report schedule is tied to the account that created it. When that person changes role or leaves, the schedule can keep sending data to recipients nobody reviews anymore. Keep an inventory of schedules with their owner, dashboard, recipients and purpose, and make ownership transfer part of your offboarding checklist. Ask whether your edition exposes a way to list all scheduled reports across the instance.

Rendering load from frequent schedules

Each PDF requires the renderer to load a dashboard, run its queries and draw the panels. Many dashboards on short intervals can compete with interactive users for data source capacity and renderer memory, and a slow renderer can delay or fail alert images too. Set schedule frequency from the reader's actual need, stagger jobs, and measure renderer and data source load after rollout. Confirm the concurrency settings available in your release.

Keeping pace with the security baseline

The security hardening guidance covers cookies, Content Security Policy, version exposure and the metrics endpoint, which all affect the Grafana host that generates and sends reports. Review that guidance when you upgrade, because report-related settings can change between releases. Record the Grafana and renderer versions in use, and check the release notes for any change to reporting endpoints before automation depends on them.

Questions buyers ask about Grafana PDF reports

Can open-source Grafana send scheduled PDF reports by email?

Scheduled, emailed PDF reports are a Grafana Enterprise feature according to the Grafana Enterprise documentation, so the built-in scheduling and delivery are not part of the open-source edition. Open-source Grafana can still produce PDF and PNG exports of dashboards through the Grafana Image Renderer, a separate service. Getting a recurring report out of the open-source edition therefore means building the scheduling and delivery yourself, using your own scheduler, an export call to the renderer and your mail system. Confirm with your team which of these pieces you want to own before you commit to a design.

What does Grafana Enterprise add for reporting, and what does it cost?

Grafana Enterprise generates PDF reports from any dashboard and can schedule them to be emailed to recipients, according to the Grafana Enterprise documentation. Pricing is not published as a list for the Enterprise edition, so you need a written quote from Grafana Labs. Ask whether the quote covers only the reporting feature or the full Enterprise license, whether it is annual, and what support and upgrade terms apply. Also ask about the Grafana Cloud tiers if managed hosting is an option, since the Grafana pricing page lists a Pro tier with a 19 US dollar monthly platform fee plus usage and an Enterprise tier with a minimum commitment of 25,000 US dollars per year.

How long does a scheduled reporting setup take?

The duration depends on how many dashboards, recipients and delivery paths you need, and on whether you choose Enterprise or open source. An Enterprise setup is mostly configuration, licensing and testing of schedules and recipients. An open-source setup adds the renderer deployment, token authentication between Grafana and the renderer, the scheduler and mail integration, and sizing for rendering load. No supplied figure gives a reliable duration, so ask for a timeline in the written scope that lists each deliverable and the environment it runs in. Ask the provider to state which parts depend on your identity, network and mail approvals, because those approvals often set the pace.

What does the image renderer need to run reliably?

The renderer is a separate service that Grafana calls to turn a dashboard into an image or PDF, so it needs its own host or container, network access from Grafana, and a token that both sides trust. Rendering is resource heavy when dashboards are large, use many panels or run on a schedule that produces many exports at the same time. Check the renderer's documented requirements for your Grafana version, plan the placement in your container or virtual machine estate, and test the largest dashboard you intend to export. The renderer is covered in more detail in the image rendering service topic on this site.

What must our team provide before a reporting project starts?

You will need to name the dashboards and panels that go into each report, the recipients and their access to those dashboards, the data sources the panels query, and the time ranges and variable values each report should use. You also need a hosting environment for Grafana and the renderer, a mail relay that accepts the report messages, and an owner who approves identity and network changes. If you plan to use Enterprise, you need the license and an administrator who can manage it. Ask the provider to list these inputs in the written scope so that gaps show up before the build starts.

Can our own team run and maintain a reporting setup?

Yes, if your team already operates Grafana, its database and a reverse proxy, and can add a renderer service and a scheduler to the set of systems it supports. The recurring work is upgrades, since Grafana releases new minor versions every other month and patch releases at least monthly according to the upgrade guidance, plus renderer compatibility checks, mail deliverability and failed-job monitoring. Open-source scheduling is your code or tooling, so it needs tests and a change process. If that work does not fit your team, DeployOpen can plan, implement and document the setup inside your infrastructure, and offer ongoing support and upgrades as a retainer under a written agreement.

Which edition should we choose if reporting is the only reason?

Choose the edition only after you have decided how much you are willing to build and operate yourself. Enterprise reporting is the shortest path to scheduled emailed PDFs, but it adds a commercial license that must be quoted and renewed. Open source avoids the license but moves the scheduling, delivery and renderer operations to your team or a partner. Compare the two quotes and the internal effort side by side over the same period, and include upgrades, audit evidence and support. Also confirm which other Enterprise features you need, such as SAML or SCIM, because they may change the decision more than reporting does.

Questions to settle before choosing an edition for reporting alone

Start with the reporting volume, not the price list. Count the dashboards that must become PDFs, how often each report runs, and how many distinct recipients receive them. A handful of weekly reports to a small leadership group is a different operating problem from hundreds of per-team reports fanned out to external stakeholders, because the second case multiplies renderer load, delivery failures and the list of people who must be kept up to date. Also settle whether you need scheduled delivery at all. If the requirement is an analyst exporting a panel on request, the open-source image renderer may cover it without any scheduling layer. If the requirement is a recurring email with a PDF attached, that is the feature the Enterprise edition documents, and it should be the first thing you confirm with Grafana Labs for your exact version.

Next, check whether reporting is the only reason you are looking at Enterprise. The authentication docs state that SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your identity provider policy already requires SAML or SCIM provisioning, the edition decision is driven by identity, and the reporting feature becomes a secondary benefit to measure. If your sign-in can run on the OAuth, LDAP or JWT options that every edition includes, reporting is the main claim on the license and should be tested that way. Ask for the Enterprise scope in writing, including which features and support terms apply to your version, before you commit budget to it.

Finally, name who owns the renderer and who answers when reports stop arriving. Reports depend on a separate rendering service, so someone must patch it, size it, watch it and restore it after a failed upgrade, whichever edition you run. Confirm which team owns that service, how its authentication to Grafana is configured, and how failed deliveries are noticed. Then ask whether the reporting need alone justifies Enterprise licensing once those operating costs are included. Compare the annual license quote with the staff time to run the renderer and the cost of a manual export process, and write down the answer. If the figures do not favor Enterprise, a well-run open-source instance with a managed export routine is a sound result, and it can be revisited at the next upgrade.

How DeployOpen scopes and delivers Grafana reporting

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For scheduled PDF reports from Grafana dashboards, we first settle which edition and rendering path fits your reporting requirements, then build and hand over the working setup in your environment.

How we scope

Inventory the dashboards, recipients, schedules and data sources that the PDF reports must cover
Decide between Grafana Enterprise reporting and an open-source image renderer setup, with the trade-offs written down
Record who owns report delivery, recipient lists and access to exported data before work starts
Agree the scope, deliverables and timeline in writing, since most engagements are fixed-scope

How we build

Deploy the chosen reporting path in your infrastructure, including the renderer service and its connection to Grafana
Configure the mail relay, sender identity and recipient handling you have approved for report delivery
Test sample reports against real dashboards, checking layout, time ranges, data source permissions and delivery
Document the configuration as code where the chosen setup supports provisioning, so changes can be reviewed

How we hand over

Deliver runbooks covering schedules, report ownership, renderer sizing and common failure modes
Provide a record of the settings, versions and access rules used for the reporting setup
Walk your operators through checking that scheduled reports ran, and what to do when one fails
Confirm with your team which upgrade and patch steps affect the renderer and reporting features

How we support

Ongoing support, upgrades and continuous testing are available as a retainer
Retainer scope can cover renderer updates after Grafana releases and checks on report delivery
Ask for the support boundaries, response expectations and change process in the written agreement
Ask for a quote built from the written scope, since DeployOpen does not publish a price list

Scheduled PDF reports from Grafana dashboards