Is a Datadog public dashboard URL authenticated?

No. Sharing a dashboard publicly produces a URL that anyone can open without logging in to Datadog, optionally restricted to an allowlist of email addresses or an embed. Treat the unrestricted form as publishing your infrastructure metrics — host names, service names and traffic shapes are all inferable from a metrics dashboard.

Can I share a single Datadog graph instead of the whole dashboard?

Yes — embeddable graphs produce an iframe snippet for one visualization. It is narrower than a full public dashboard, and it is still an unauthenticated URL that renders live data to whoever holds it.

Does sharing a Datadog dashboard cost a seat?

Viewing a dashboard inside Datadog requires a user in your organization, and Datadog bills per user by plan. The public-sharing and embed routes exist precisely to avoid that, at the cost of dropping authentication.

How do I send reliability numbers to someone without giving them Datadog access?

Query the metrics through the Datadog API, render them into one self-contained HTML page, and publish that page to a stable URL with an anchored comment layer. The reader gets the numbers with no seat and no permanently open public dashboard.

How do I keep one URL week to week?

Publish once, keep the report id, and PATCH it on each scheduled run. Revisions stack at the same URL, so a link in a channel topic or an SLA document stays correct and two weeks can be compared.

How to share a Datadog dashboard

Datadog gives you two ways to show a dashboard to someone who is not in your organization, and both of them work by removing authentication. That is the trade to understand before you click anything.

The options

Invite them. A user in your Datadog org sees the dashboard live, with all the drill-downs. Correct for engineers. Billed per user, and it grants access to considerably more than the one dashboard.

Share publicly. The dashboard gets a URL that opens without a login. You can restrict it to an allowlist of email addresses, which is meaningfully better than fully open, or leave it unrestricted, which means anyone with the link sees live production metrics. Worth being blunt about what a metrics dashboard leaks even without a single business number on it: service names, host counts, deploy cadence, traffic shape, and when you are busiest. That is a reconnaissance document.

Embed a graph. The narrower version — an iframe snippet for one visualization. Same property: an unauthenticated URL rendering live data.

Screenshot it into Slack. What most people actually do, and it produces an image nobody can quote a number from, with the discussion scattered across a channel that scrolls away.

The gap

The recurring need is a specific audience — an account manager, a customer's technical contact, a compliance reviewer, an exec — who needs last week's reliability numbers, as text, at a link that opens, with somewhere to ask whether a spike was expected.

Public sharing gives the link and drops the access control. Inviting them gives the access control and costs a seat plus far too much scope. Neither leaves a record anyone can read back through.

The digest pattern

Query the metrics, render one self-contained HTML page, publish it at a stable URL, and put anchored comments on top.

Datadog's API returns timeseries as JSON, so nothing has to be scraped:

curl -fsS -G "https://api.datadoghq.com/api/v1/query" \
  -H "DD-API-KEY: $DD_API_KEY" -H "DD-APPLICATION-KEY: $DD_APP_KEY" \
  --data-urlencode "from=$(date -d '7 days ago' +%s)" \
  --data-urlencode "to=$(date +%s)" \
  --data-urlencode 'query=avg:trace.http.request.duration.by.service{env:prod} by {service}' \
  > latency.json

Turn that into an HTML table of p50/p95/p99 per service plus a couple of inlined sparklines, keep the file self-contained — no CDN, nothing fetched at view time — and publish it:

python3 scripts/datadog_digest.py latency.json > digest.html

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html digest.html \
        --arg title "SLO review — week of $(date +%F)" '{title: $title, html: $html}')"

A routine runs the same job on a schedule if you would rather not add another cron.

Why this beats both Datadog options for this audience

You choose what leaves. A digest contains the three SLOs you meant to report, not every service name in the org. That is a smaller disclosure than a public dashboard by an enormous margin.

Access is real. Visibility is a setting on the report — private, team, domain-gated or link — so "anyone at customer-co.com" is enforced rather than hoped for.

There is a record. Each week is a revision at the same URL. "Did we breach in March" is a question with an answer, instead of a re-query against a retention window.

The conversation attaches. Someone highlights the Tuesday p99 and pins "deploy 4.2 rollback, INC-2214, expected." That thread persists across revisions, so the next reader inherits the explanation.

An agent connected through Comma's MCP server can read those threads too, which puts the accumulated incident context where the next triage can use it.

When to just use Datadog

Engineers who will drill into a trace should be in Datadog. Nothing static replaces a live APM view for someone doing an investigation. The digest is for the readers who should never have that access, and for the weeks you want a dated, quotable, commentable record of what reliability actually was.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Create your first report →