Azure Managed Grafana: Scheduled PDF report generation fails intermittently and silently (no error, no email)

Hello Regina Michel

Thank you for posting your query on Microsoft Q&A platform.

You've already found the 200-second cap and the ~10s average per-panel render time. The key detail is that the ~10s is an average, not a fixed cost — the documented figure assumes the data query for that panel completes in under one second (Use reporting and image rendering in Azure Managed Grafana). In practice, per-panel time = browser render + query time, and query latency against Azure Monitor, Log Analytics or ADX varies from run to run depending on backend load, caching and throttling.

That's why the boundary isn't a clean panel-count threshold. A report sitting at 12–13 panels lands close to 200 seconds, so small variations in query latency decide whether it finishes or gets cut off. Your data (9 panels always fine, 14–15 always failing, 10–13 mixed) matches that behaviour exactly.

Your top-of-the-hour result is the other half of the picture. 52.9% when everything fires at :00 versus 75% when staggered five minutes apart is a strong indication of contention on the image renderer, which has fixed capacity per workspace. The same doc notes that overloading the renderer can make it unstable, and that alert screenshots draw on the same renderer.

One more failure mode worth ruling out: Grafana does not send attachments larger than 10 MB by default, to stop mail servers rejecting them (Create and manage reports). This limit isn't customer-configurable on Azure Managed Grafana. If the PDFs that do arrive are anywhere near 10 MB, that could be causing some of your silent drops independently of the timeout — worth a quick check.

I want to be straight with you here rather than point you at a document that doesn't exist: there is no Microsoft article that resolves the missing error notification or the missing report run history. That behaviour sits in the Grafana reporting feature itself, which is why your GitHub issue is the correct place for it.

It's also not something you can work around by digging into logs on Azure Managed Grafana. Diagnostic settings for the Microsoft.Dashboard/grafana resource type currently support Grafana login events only — audit logs and metrics are documented as not supported.

Reference: Monitor Azure Managed Grafana using diagnostic settings.

And renderer internals aren't reachable because the Grafana Server Admin role isn't available to customers and the Admin API is disabled (Service limits, quotas, and constraints).

So the realistic approach is to keep reports comfortably inside the budget rather than near the edge, and to detect misses outside Grafana.

Aim for around 8–10 panels per report, not 20. The 20-panel figure in the docs is an upper bound, and it drops further if you attach CSV. Targeting roughly half the time budget gives you headroom for query variance. Splitting one large dashboard into two or three smaller report dashboards is more effective than trimming a borderline one.

Cut query time, not just panel count. Shorten the report time range, pre-aggregate where you can, and use table format instead of time series for heavy panels — the limits doc specifically recommends this for Azure Data Explorer, along with avoiding many panels querying the same cluster at once. Your sweep showed the time series panels were driving the failures, which fits.

Widen the stagger. Five minutes already got you to 75%. Since a single report can legitimately hold the renderer for up to 200 seconds, 10–15 minutes between reports is safer, and moving them off the top of the hour avoids competing with dashboard refreshes and alert screenshots. If you have alert rules with screenshots enabled, limiting those to the ones that truly need them frees up renderer capacity too.

Drop CSV attachments from reports that don't strictly need them.

Replace the weekly manual check with automated detection. Since run history isn't available through the API, verify at the delivery end instead, add a monitored mailbox as an extra recipient, then use a scheduled Logic App to check whether each expected report arrived in its expected window, with an Action Group alert when one doesn't. It won't retry for you, but it turns a weekly manual sweep into a notification within minutes.

Hope this helps clarify things.

Best regards,

Suchitra