Loading today’s stories
Build1 distinct publisher3 min readUpdated
One structured JSON endpoint replaces the per-product source-IP lists, .txt files and DNS records. The old paths keep working until 2027, and the parser rewrite is yours.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Grafana Labs has replaced the collection of per-product source-IP lists for Grafana Cloud with a single Allowlist API that serves current addresses as structured JSON over HTTPS [1]. The legacy formats keep working and stay up to date until January 31, 2027 [2], which is the only detail that matters for planning: this is a dated ticket, not an announcement.
If you do not use IP allowlisting, or you reach Grafana Cloud over private connectivity such as AWS PrivateLink, Grafana says nothing changes and no action is needed [3].
For everyone else, the old arrangement was one JSON list, one plain-text list and one DNS record per product, for example https://grafana.com/api/hosted-metrics/source-ips, its .txt twin, and the src-ips.hosted-metrics.grafana.net lookup [4]. Keeping firewalls current meant polling several lists and stitching them together yourself [5]. The replacement is three shapes of one endpoint: global at https://allowlists.grafana.net/v1/ [6], per region at https://allowlists.<your-region>.grafana.net/v1/ [7], and per service at https://allowlists.<your-region>.grafana.net/v1/<service> [8]. Each service entry carries a traffic direction, either ingress-to-grafana or egress-from-grafana, plus IPv4 CIDR ranges, under a metadata block naming the schema version and region [9]. Valid service names are grafana, metrics, logs, traces, profiles, otlp, alerts and fleet-management [10], eight in total [11].
Grafana is explicit that this is not a drop-in URL change [12]. The legacy endpoints return flat JSON arrays, plain-text lists or DNS records; the new one returns nested JSON with CIDR ranges and direction metadata, so parsers have to be rewritten rather than repointed [12]. Names move too: hosted-metrics becomes metrics, and both hosted-grafana and grafana-assistant collapse into grafana [13]. BYOC customers cannot use the global endpoint at all, because BYOC regions are excluded from it, and must call their regional URL [14]. Your stack's region is on the instance details pages in the Grafana Cloud stack [15].
The migration guidance is unremarkable and therefore worth following. Inventory every reference to grafana.com/api/*/source-ips, the .txt variants and src-ips.*.grafana.net records, including Grafana Assistant records [16]. Where you can, allow the union of legacy and new addresses during the overlap, and validate telemetry delivery, queries and alert notifications before cutting over [17]. Fetch the API on a schedule instead of pasting addresses into long-lived firewall config, because the addresses change [18]. And treat each traffic path separately: private connectivity via AWS PrivateLink, GCP Private Service Connect or Azure Private Link removes the need for an allowlist, but traffic that stays on the public internet, such as Grafana Cloud reaching your external data sources or notification endpoints, still needs one [19].
Two things to watch. The published schema exposes a direction field and an ipv4 field [9]; there is no IPv6 equivalent in the documented response, so dual-stack estates should ask support what covers the v6 side [20]. Second, the metadata declares schemaVersion v1 [9], which implies a v2 someday, so whatever you build should fail loudly on an unexpected schema rather than silently emitting an empty ruleset. One scheduling note: January 31, 2027 is a Sunday [21], so the practical deadline for a supervised cutover is the working week before it, and the real risk is a firewall config nobody has touched since 2025 quietly going stale in the months before that.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Grafana Cloud introduced a new allowlists design: a single, structured API that replaces the collection of per-product IP lists published until now, serving current IP addresses as structured JSON over HTTPS. The new Allowlist API is available now.
All the legacy per-product formats - the JSON lists, their .txt equivalents, and the src-ips.<product>.grafana.net DNS records - will continue to work and stay up to date until January 31, 2027, to allow teams to plan and execute migration.
Grafana Labs states that customers who do not use IP allowlisting, or who connect to Grafana Cloud over private connectivity such as AWS PrivateLink, are unaffected and need take no action.
Until now Grafana Cloud published source IP addresses through per-product endpoints and formats: a separate JSON list, plain-text list, and DNS record for each product, for example https://grafana.com/api/hosted-metrics/source-ips, its .txt equivalent, and the src-ips.hosted-metrics.grafana.net DNS lookup.
Keeping firewalls in sync under the legacy design meant polling several different lists and stitching them together yourself.
The global endpoint https://allowlists.grafana.net/v1/ covers all services for all Grafana Cloud regions.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific first-party documentation, unverified externally
The single supplied source is the vendor's own announcement and it is unusually concrete: exact endpoint URLs at three scopes, a sample response with schemaVersion and direction fields, an enumerated list of eight service names, explicit legacy-to-new name mappings, the BYOC exclusion, and a hard removal date of January 31, 2027. That is authoritative for a vendor describing its own API. It is capped by there being exactly one publisher, no independent or customer-side confirmation that the endpoints behave as documented, and no publication date on the item.
No adoption data in the supplied sources
The material establishes only that the API is available and that legacy formats are dated for removal. There are no usage figures, no customer or partner migrations, no third-party tooling updates and no dated deployment events in the cluster, and the sole source carries no publication date. Nothing here supports an adoption measurement, so none is inferred.
Slightly understated relative to the work it creates
The announcement makes no outsized claims: benefits are stated as one format, finer granularity and clearer traffic direction, and the breaking nature of the change is disclosed head-on ('this is not a drop-in URL change'). If anything the framing is quieter than the consequence — a dated removal of DNS records and text lists that live inside firewall automation is a compliance-style deadline for every allowlisting customer, presented as a design refresh with migration tips. That tilts marginally negative rather than overstated.
Vendor announcing and justifying its own deprecation
The only publisher is the party making the change, and it benefits twice: retiring a per-product patchwork it maintained, and framing that retirement as a customer usability win ('easier to parse, automate, and validate'). It also routes questions to its own support team. Countervailing signals keep this mid-range rather than high: a long dual-run window, explicit admission that automation breaks, and clear advice to use private connectivity and skip allowlisting entirely where possible.
Facts are firm, context is thin
The operational specifics can be relied on because the vendor is authoritative about its own endpoints and stated a dated removal in writing. Confidence is held below high because the cluster has one publisher and one item, the item has no publication date, adoption is unmeasurable, and material follow-on questions — IPv6, endpoint availability guarantees, notification of CIDR changes, tooling — are unanswered in the supplied text.
build
Your meter now runs on someone else's machine: signed receipts, fsync, and failing open1 distinct publisher
product
Docker puts Verified Publisher behind a signup form, and pull data behind a plan1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.