When teams need externally shared Grafana dashboards and what they can show
Use an externally shared dashboard when a team must show operational status to customers, auditors or partners who will never have a Grafana account. In Grafana, this capability was previously called public dashboards, and it gives anyone with the link read-only access to a dashboard without signing in. It suits content that is safe to show to the outside world, such as service availability panels, uptime summaries or a fixed set of agreed reporting metrics. It does not suit dashboards that expose internal host names, customer identifiers, internal annotations or anything that would be sensitive if a link were forwarded.
Do not confuse external sharing with sharing to named people. Sharing with specific individuals is in private preview and requires Grafana Enterprise or Grafana Cloud, so an open-source deployment cannot rely on it. Confirm the current state of that feature in the Grafana documentation before you promise it to a stakeholder, because preview features change between releases. Also confirm which edition and plan your organization holds, since the answer decides whether you can offer per-person access at all.
Before committing, review the page as an outsider would see it and check what the shared view actually contains. The Grafana shared dashboards documentation lists the supported data sources and the features that stop working on shared views, and it is the reference to check against your own panels. Treat the review as a gate: a dashboard that depends on template variables, library panels or unsupported data sources needs redesign before it is shared, not after.
Which data sources and features work on a shared dashboard
The Grafana shared dashboards documentation confirms a set of data sources for externally shared dashboards. Panels that query these sources can run for viewers who have no account, but each one still runs the queries stored on the dashboard and nothing else. The confirmed list covers relational, analytical, log, search and metrics systems, so most operational dashboards built on them are candidates for sharing.
- ClickHouse and MySQL or PostgreSQL: Confirmed for shared dashboards. Check that the database user behind the data source is read-only and limited to the tables the dashboard needs.
- Microsoft SQL Server: Confirmed. Apply the same read-only, least-privilege review to the service account.
- Prometheus, Loki and InfluxDB: Confirmed. Queries run against the backend on each viewer load, so refresh intervals matter (see the query load tab).
- CloudWatch, Elasticsearch and Infinity: Confirmed. These sources often hold cloud or log data, so confirm which indices, log groups or endpoints the stored queries can reach.
- Version and edition: Confirm the supported list against the current Grafana release notes, since the list can change between versions.
After publishing, open each panel from a shared link in a private browser session and confirm it renders with the expected data.
Some data sources are not supported on externally shared dashboards. Panels built on them either fail to load for viewers or cannot be shared at all, so a dashboard that mixes supported and unsupported sources will show errors in the unsupported panels. The Grafana documentation names three unsupported sources, and the exclusion affects the design of dashboards that depend on them.
- Graphite: Not supported. Plan a supported source for any panels that need the same metrics, or keep those panels in the internal dashboard.
- Tempo: Not supported. Trace panels for shared viewers need a different design, such as exporting results to a supported store.
- Zabbix: Not supported. Teams that monitor infrastructure with Zabbix should keep Zabbix panels off externally shared dashboards.
- Mixed dashboards: A single unsupported panel can make the whole review look broken, so remove or replace it before sharing.
- Support changes: Confirm the list against the current documentation before you commit, because support can change between releases.
Before you share, scan every panel and data source on the dashboard and compare them with the confirmed and unsupported lists.
Some Grafana features do not work on externally shared dashboards, even when the data source itself is supported. These limits come from the sharing model, which gives viewers only the stored queries on the dashboard. Dashboards built around interactive features need to be redesigned or kept internal.
- Template variables and queries with variables: Not supported. Hard-code the values each panel needs, or create one shared dashboard per value.
- Library panels: Do not work on shared dashboards. Copy the panel definition into the dashboard if the viewer needs it.
- Grafana Live: Does not work. Streaming panels need to refresh on a timer or stay internal.
- Reverse proxy data sources: Do not work. Viewers cannot reach these sources through the shared link.
- Interactive changes: Viewers cannot change the query or variable values, so plan the dashboard as a fixed view.
Re-test each panel on a shared link after every change, because a feature that works in the editor can still fail for viewers.
Why template variables break shared dashboards
A viewer of an externally shared dashboard can only run the queries stored on that dashboard. Template variables are not supported on shared dashboards, and queries that depend on a variable do not work either. A dashboard that asks the viewer to pick a host, service or cluster from a dropdown will therefore show panels that fail or stay empty for the anonymous audience, even though the same dashboard works fine for internal users. Before you publish, open each panel in the dashboard and confirm that its query runs with the variable values hard-coded, because a panel that looks correct in the editor may still depend on a variable that the shared view cannot resolve.
The practical consequence is that dashboards built around per-host or per-service variables need a different publishing plan. The usual pattern is to publish a fixed version of the dashboard for one scope, with the query text set to the specific host, service or cluster, or to create a separate dashboard for each scope that the external audience needs. Both options create maintenance work, since every change to the internal dashboard must be carried into each published copy. Ask the dashboard owner which scopes are truly external, keep the number of published copies small, and record which internal dashboard each copy came from so that a later edit does not leave an outdated view online.
Your variable design decisions affect this work more than most teams expect, so settle them before you choose what to share. The dashboard variables and repeating panels topic covers how to structure variables, chain them and keep sensitive values out of URLs. Read it with this limit in mind: a variable that works well for internal exploration may be the reason an external view has to be rebuilt. Confirm the current behavior of variables on shared dashboards in the Grafana documentation for your version, since the supported feature set for this sharing model is still changing.
How anonymous traffic adds query load on your data sources
Anonymous viewers run the queries stored on a shared dashboard, but they do not sign in, so nothing about their traffic is limited by user identity. The cards below cover what multiplies that load, what the data source sees, and the controls you have to put in front of it.
Stored queries run without a session
Viewers of an externally shared dashboard run only the queries saved on it, and they do so without a Grafana user session. That removes the per-user context you would normally use to throttle or attribute load. Confirm with your own test instance which queries run on each page view, and list them against the data source each one hits before you publish.
Refresh intervals multiply load
Every open browser tab on a shared dashboard repeats its panel queries on the refresh interval, so load grows with the number of anonymous viewers rather than with the number of dashboard authors. A 30-second refresh across a few hundred open tabs is far more query traffic than the same dashboard viewed once. Set a conservative refresh interval on the shared dashboard and remove auto-refresh where the data changes slowly.
No per-viewer caching assumptions
Do not assume that Grafana or your data source will serve repeated anonymous views from a cache. Caching depends on your data source, your query cache settings and any proxy in front of Grafana, and each viewer's request may still reach the database. Ask the data source owner whether results are cached, for how long, and whether the cache key includes the time range.
Wide time ranges cost more
A panel that reads a 90-day window scans far more rows than one reading the last hour, and anonymous viewers can pick up that cost without any authoring change. Choose time ranges and aggregation intervals in the stored queries themselves, since viewers cannot narrow them with template variables on shared dashboards. Check the query plan or cost estimate on your largest data source before publishing.
Shared data source credentials
Each anonymous view runs under the credentials configured for the data source, not under an individual's permissions. That means every public viewer consumes the same service account quota, connection pool and rate limit. Use a read-only account scoped to the tables or indexes the dashboard needs, and confirm that the account's connection limits can absorb peak anonymous traffic.
Rate limiting and caching at the edge
Put controls outside Grafana where your data source cannot protect itself: rate limits at the reverse proxy or API gateway, response caching for identical queries, and connection pool limits on the database side. Test these controls with a load tool that mimics many anonymous tabs, and measure query volume on the data source before and after publishing so you can see the change your dashboard causes.
The annotation leak to check before you share
Before you share a dashboard externally, check its annotations. On a shared dashboard, tag-based annotation queries return matching annotations from all dashboards in the organization, not only from the dashboard being shared. An annotation written for an internal incident, a customer name or a remediation ticket on a different dashboard can therefore appear to an anonymous viewer if its tag matches a tag the shared dashboard queries. The leak is not a bug in one panel. It is a consequence of how the annotation query is scoped, so the dashboard can look clean while still exposing text from elsewhere in the organization.
Run a check in this order. First, list the annotation tags in use across the organization, from the annotation data in each dashboard and any tags your teams commonly apply. Second, search the text of those annotations for sensitive terms such as internal host names, incident code names, customer identifiers, ticket references and personal data. Third, for each tag the shared dashboard queries, decide whether every annotation carrying that tag is safe for an outside reader. If not, remove the sensitive annotations, rename the tag used on the shared dashboard so it matches only curated annotations, or remove the annotation query altogether. Repeat the check after any new incident, because new annotations are added continuously. Illustrative example: a team tags deployment markers prod on every dashboard, and an incident note mentioning a customer name carries the same tag. Renaming the shared dashboard's tag to a dedicated one for approved markers closes that path.
Where shared content and internal operations cannot be separated by tags, consider a separate organization for the shared content, so that the annotation query only sees annotations written inside that organization. Confirm how annotation scope behaves in your Grafana version and edition before relying on it, and record the check and its owner as part of your sharing approval, since the annotation set changes over time.
How to publish a shared dashboard safely
This sequence confirms that external sharing is available and allowed in your edition, then builds, tests and audits a dashboard so that anonymous viewers see only what you intended. It ends with a named owner and a scheduled review.
Confirm edition and sharing availability
Before anything else, the platform owner confirms which Grafana edition runs the instance and whether external sharing is enabled and permitted by policy. Sharing with specific people is limited to Grafana Enterprise or Grafana Cloud, so an open-source instance should be checked against the shared dashboards documentation for the version in use. Confirm the setting with your own administrator rather than assuming a default. The step is done when the owner has written down the edition, the version and the approved sharing mode.
Build the dashboard with fixed queries
The dashboard author builds the dashboard with every panel using a fixed query, without template variables or queries that depend on variables. Shared dashboards do not support variables, and library panels, Grafana Live and reverse proxy data sources do not work on them, so panels that rely on those features need to be rebuilt first. Use only the supported data sources listed in the shared dashboards documentation, and confirm each one against your version. The step is done when a reviewer can open the dashboard JSON and find no variable references and no unsupported panel types.
Test every panel in a private session
The author opens the shared link in a private browser window with no Grafana login, then checks each panel, legend and time range. Viewers without accounts can only run the queries stored on the dashboard, so any panel that errors, shows an empty result or asks for input is a defect to fix before publishing. Record which panels passed and which were changed. The step is done when every panel renders correctly in the anonymous session and the test is attached to the change record.
Audit annotations and tags
A second reviewer checks every annotation query on the dashboard. Tag-based annotation queries return matching annotations from all dashboards in the organization, so an annotation tagged with a common label can expose text written for internal teams on another dashboard. Remove tag-based annotation queries that are not needed, narrow the remaining ones, and review the annotation text that would be visible. The step is done when the reviewer signs off that no annotation shown to anonymous viewers contains information meant for internal use only.
Check data source credentials and query cost
The platform owner checks which credentials the shared queries use and what each refresh costs the data source. Viewers can trigger the stored queries repeatedly, so a heavy query on a shared dashboard creates load that does not depend on how many people you intended to reach. Confirm that the credentials are read-only, scoped to the data needed, and not personal accounts, and confirm with the data source team how much load the refresh interval and time range will add. The step is done when the owner has documented the credentials, the query cost and an agreed refresh interval.
Record owner and schedule review
Before publication, the dashboard owner records a named person responsible for the dashboard, the business reason for sharing, the approved audience, and the date of the next review. The review should repeat the annotation audit and the credential check, because later changes to shared panels or tags can reintroduce exposure. Store the record next to the dashboard in your change system. The step is done when the record exists, the owner has accepted it, and the review date is on a team calendar.
Security controls to review on a self-hosted instance
A public link is only as safe as the instance and account behind it. The controls below cover what the internet can reach, what the anonymous viewer's data source can read, how the instance is hardened, who is allowed to publish, and how shares are withdrawn when the content changes.
Instance exposure to the internet
Shared dashboards are served from the same Grafana instance that your staff use, so the instance itself becomes reachable from outside. Decide which hostname serves shared links, keep administrative sign-in and the rest of the UI off that path where your network allows, and confirm that the reverse proxy and load balancer in front of Grafana forward only the routes you intend to publish. Test from outside your network after each change.
Read-only data source account
Anonymous viewers run the queries stored on a shared dashboard using the data source credentials configured on the server. Give that data source account read-only access to the specific tables, indices, buckets or label sets the dashboard needs, and nothing broader. Treat any credential reachable from a shared panel as one you would expose to the public, and rotate it when a share is retired.
Cookie and browser hardening
Grafana's security hardening guidance recommends secure and SameSite cookies, which reduce the chance that session cookies are sent in cross-site requests or over plain HTTP. Pair these with a Content Security Policy and Trusted Types so injected script in a panel or plugin has less room to run in the browser of a visitor who is not signed in. Confirm each setting in your configuration file and check the response headers on a shared page.
Hidden version and domain checks
Hiding the Grafana version from unauthenticated users keeps the public-facing pages from advertising which release is running, which makes targeted vulnerability matching harder. Domain verification guards against DNS rebinding, where a hostile site uses a hostname it controls to reach the internal service. Confirm both settings in your configuration and check that the domain list matches the names your users type into their browsers.
Who can publish shares
Creating a shared link is an action that needs its own review, separate from editing a dashboard. List the users and roles that can turn sharing on for each dashboard, and check how that matches your folder permissions. Review this list on a fixed schedule and after staff changes, because a shared link is created once but stays public until someone removes it.
Revoking shares when content changes
A shared dashboard keeps showing its stored queries after the business context changes, so a panel that was safe to publish last quarter may not be safe now. Set a rule that a dashboard is re-reviewed before each significant edit, and revoke its share when the panels, queries or annotations no longer match what the public should see. Check the share list after reorganizing folders, since a moved or renamed dashboard can keep its existing link.
Questions teams ask before sharing Grafana dashboards externally
Can open-source Grafana share dashboards with specific named people?
No. Sharing a dashboard with specific people is in private preview and needs Grafana Enterprise or Grafana Cloud, according to the Grafana shared dashboards documentation. The open-source edition offers externally shared dashboards, which anyone with the link can view without an account, so the audience cannot be narrowed to a list of people. If your policy requires named recipients, your options are an Enterprise or Cloud license, a sign-in layer in front of the instance, or a different delivery method for those recipients. Confirm the current status of the named-person feature before you commit, because a private preview can change between releases.
Do shared dashboard links expire, and can you revoke them?
Confirm this in the documentation for your Grafana version before you publish, because the supplied information does not settle it. Ask whether a shared dashboard supports an expiry setting, how access is revoked, and who can switch sharing on or off. Then test each answer on a non-production instance: publish a test dashboard, open its link in a private browser session, disable sharing, and reload the link. Record the result in your publish checklist. Also review who holds Editor or Admin rights, because those roles can create new shared dashboards unless your folder and role model prevents it.
How much effort does a safe publish take, and what drives it?
The effort depends on the dashboard, not on a fixed package, so the number of panels and data sources matters more than the sharing step itself. The main drivers are the number of queries that run from the dashboard, whether any panels use template variables (which shared dashboards do not support), whether the dashboard relies on library panels or unsupported data sources, and how many annotation queries use tags. The one-time work is the review and the fixes; the recurring work is re-checking the dashboard after each change and after each Grafana upgrade. DeployOpen agrees a fixed scope and deliverables in writing before work starts, so a quote follows from the dashboards and data sources you list.
Can our own team publish externally shared dashboards without a partner?
Yes, if the team can cover the checks. A team with Grafana administration skills can confirm the data source list, remove or rewrite variable-dependent queries, inventory annotations, and test each dashboard from an unauthenticated browser. The harder part is repeating that work for every new dashboard and after every change. The annotation behavior in the shared dashboards documentation affects every dashboard that uses tag-based annotation queries in the organization, so one careless publish can expose data that belongs to other dashboards. If the team lacks the time or the review skills, DeployOpen can run a fixed-scope review or an ongoing retainer for the same checks.
What does a shared dashboard project need from our team?
The project needs decisions and access from your side, not only infrastructure:
- Read-only data source accounts so the team can test every stored query against the same sources the dashboard uses.
- A named owner for each dashboard who signs off on what the audience may see.
- A complete annotation inventory for the organization, including which tags each annotation query matches.
- A list of confirmed data sources, checked against the supported list in the documentation for your version.
- A non-production instance and a test network path that matches the external audience's access.
Without these inputs, the review cannot confirm what an outside viewer will actually see, so ask for them in the written scope before work begins.
Should we share a dashboard externally or embed it in our application?
Share externally when the audience needs a read-only view, has no account, and the dashboard uses supported data sources without template variables. Embed when the panels must sit inside your own product, when your application must control sign-in, or when each user needs a different filtered view. Shared dashboards do not support template variables, so per-user filtering is a strong signal toward embedding with authentication. Confirm which embedding approach supports your identity model and data access rules in your Grafana version, and compare the exposure of each option with your security team before you choose.
Does an externally shared dashboard add load to our data sources?
It can. Viewers of a shared dashboard run only the queries stored on it, so the load comes from how many people open the link, how often panels refresh, and how expensive each query is. Anonymous traffic can arrive in bursts that your internal users never produce, which makes refresh intervals and query cost the main controls. Before publishing, measure the query time of each panel against your data sources, set conservative refresh intervals, and consider precomputed results such as recording rules for heavy aggregations. Confirm how caching and refresh behave for shared views in your Grafana version, and load-test the dashboard with realistic concurrency before the external audience arrives.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Grafana inside your own infrastructure, so sharing decisions are made against your data sources and access model. We start by agreeing in writing which dashboards may be shared outside your organization, what each one queries, and how annotations and data source load are checked before anything is exposed.
How we scope
- Inventory every dashboard proposed for external sharing, including its panels, data sources and any template variables it relies on.
- Record which Grafana edition and sharing feature you run, since sharing with specific people needs Grafana Enterprise or Grafana Cloud.
- Confirm which data sources are supported for shared dashboards and which need a different approach, such as an internal view.
How we build
- Rework dashboards that depend on template variables, library panels or reverse proxy data sources into fixed queries before sharing.
- Review each shared query for load on the source database and set limits or caching where the data source supports them.
- Test annotation queries on every shared dashboard to confirm no entries from other dashboards in the organization are returned.
How we hand over
- Deliver a written register of shared dashboards, their queries, data sources and the owner responsible for each one.
- Document the annotation check, the data source load review and the steps to revoke or unpublish a shared dashboard.
- Run a walkthrough with your platform and security teams so they can repeat the checks when a dashboard changes.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover re-checks after Grafana upgrades.
- Ask for a quote based on your written scope, since DeployOpen does not publish a price list.
