Labels will appear exactly as you define them. A three-stage migration (prefixed → dual-write → un-prefixed) is open now. Support for the legacy prefixed behavior ends March 1, 2027, after which any stack not yet migrated will be auto-migrated by Grafana Labs.

Why we’re changing it

Previously, filtering a dashboard, scoping an alert, or attributing cost by team or service required joining sm_check_info against the check metric you actually wanted, and remembering that team actually renders as label_team. This made Synthetic Monitoring an exception to how labels work everywhere else in Grafana Cloud.

With labels on the metrics themselves, a single alert rule can route by team, Cost Management can attribute usage by your own dimensions, and there is no separate label convention to learn.

Read the blog post for more detail.

What is not changing

If you do not use custom labels in Synthetic Monitoring, nothing changes and no action is needed. System-defined labels are unaffected. Historical data is not lost: everything already collected remains queryable under its original label names for your retention window, during and after migration.

The migration does not increase cardinality or cost; the dual-write period where both label sets exist is absorbed by 95th-percentile billing and is not billed as additional active series.

What to check before this rolls out

• If you use custom labels in Synthetic Monitoring, check them against the reserved system labels list. Migration will be rejected if any of your labels collide with a reserved value.
• Follow the label migration guide to enable dual-write, update dashboards, SLOs, alerts, and queries that reference label_-prefixed labels or join on sm_check_info, then retire the prefixed labels. Admin access is required.
• Complete the migration before March 1, 2027 so you control the timing rather than being auto-migrated.
• If you do not use custom labels in Synthetic Monitoring, no action is needed.

The old endpoints still work, but are now marked deprecated:

• POST /api/user/stars/dashboard/uid/{dashboard_uid} (star a dashboard)
• DELETE /api/user/stars/dashboard/uid/{dashboard_uid} (unstar a dashboard)

The replacement is:

• PUT /apis/collections.grafana.app/v1alpha1/namespaces/{namespace}/stars/user-{your_user_uid}/update/dashboard.grafana.app/Dashboard/{dashboard_uid} (star)
• DELETE /apis/collections.grafana.app/v1alpha1/namespaces/{namespace}/stars/user-{user_uid}/update/dashboard.grafana.app/Dashboard/{dashboard_uid} (unstar)

No request body is needed; the star target is fully described by the URL path.

Why we’re changing it

Starring used to need one endpoint per resource kind. The new Collections Stars API stars any resource kind (dashboards today, with other kinds such as folders already supported) through the same endpoint shape, so integrations that work with starring don’t need a separate code path for every type of resource.

What to know before this rolls out

• If you call POST or DELETE on the deprecated path directly (outside the Grafana UI), plan to move to PUT/DELETE on the new path.

• Look up your own user UID from the uid field of GET /api/user to build the user-{uid} resource name; it is not your username or numeric user ID.

• Use the same {namespace} you already use for other Grafana App Platform APIs (default for the default organization on self-managed, or your stack’s namespace on Grafana Cloud).

• Treat 200 OK as success for both star and unstar, and 204 No Content as a no-op success when unstarring something that was never starred.

• Apache Cassandra
• Amazon DynaomoDB
• BoltDB (for indexes)
• Google BigTable
• gRPC Store

Loki 4.0 will fail to start if a deprecated and removed storage backend is referenced in the schema or storage configuration.

One of the reasons for making this change is to have a consistent storage configuration across Grafana Loki, Mimir and other telemetry databases from Grafana Labs.

Why we’re changing it

The Infinity data source covers the same CSV and JSON workflows as these two plugins, and adds support for authentication methods, alerting, and other backend operations that the CSV and JSON API data sources don’t support. Consolidating on Infinity gives you one actively developed data source for URL and file-based data instead of two narrower plugins.

What is not changing

Your existing dashboards and queries built on the CSV or JSON API data sources keep working exactly as they do today. Neither plugin is removed on February 1, 2027: only non-security updates stop. Critical security fixes continue for both plugins after that date.

What to check before this rolls out

• If you use the CSV data source, migrate to the Infinity data source before February 1, 2027. The Infinity data source CSV learning path walks through using Infinity for CSV workflows.
• If you use the JSON API data source, migrate to the Infinity data source before February 1, 2027. The Infinity data source JSON learning path walks through using Infinity for JSON workflows.
• If you use neither data source, no action is needed.

Why we’re changing it

Parca has low usage relative to other continuous profiling data sources. Grafana Pyroscope (self-managed) and Grafana Cloud Profiles (Grafana Cloud) are the supported paths forward. Both use the same flame graph panel you already use to visualize Parca profiles, and Cloud Profiles adds Profiles Drilldown for exploring profiles without building a dashboard first.

What is not changing

Your existing dashboards built on the Parca data source keep working exactly as they do today. The plugin is not removed on January 2, 2027: only non-security updates stop. Critical security fixes continue after that date.

What to check before this rolls out

• If you use the Parca data source, plan a migration to Grafana Pyroscope if you’re self-managed, or Grafana Cloud Profiles if you’re on Grafana Cloud, before January 2, 2027.
• If this deprecation will cause issues for you, share your feedback so the team can gauge impact before support ends. If Aha! isn’t an option for you, post in the Grafana community forum instead.
• If you use neither data source, no action is needed.

An agent that uses these queries returns the same numbers you see on the page. Without access to these queries, the agent can get incorrect results. Ask an agent to count the Nodes in a Cluster that has three, and it can answer six, because more than one source reports each Node.

An agent gets no permissions of its own. It signs in with a token, reads exactly the data that token allows, and can’t create, change, or delete anything.

1. Commands are renamed across many providers, with no aliases. Old spellings fail as unknown commands. Behaviour, flags, positional arguments, output schemas, and exit codes are unchanged, only the names moved. The aim is to make a more predictable and understandable command surface. Here are all the changes:

Six gcx assistant investigations subcommands are removed rather than renamed, because their backends do not exist for current investigations: approvals, todos, document, report, timeline, and regenerate-report.

For users of the bundled agent skills: the aio11y and aio11y-prod-setup skills are renamed to agento11y and agento11y-prod-setup, agento11y-eval-starter is renamed to agento11y-test-starter, and the explore-datasources skill is removed.

2. The configuration file format changes, with automatic migration. The config file is now versioned (version: 1) and splits into named stacks, named cloud entries, and contexts that reference them, so one Cloud token is stored once instead of repeated per context. Your existing config migrates automatically the first time the new binary loads it. The old config file is left in the same directory, for you to delete manually when you are ready.

3. Output for scripts and agents follows a strict contract. We are enforcing better consistency for output formats across all commands. When gcx detects it is being driven by an AI agent and no explicit format flag is given, every finite command now emits one JSON document on stdout (its result, or a structured error whose embedded exitCode matches the process exit code), streaming commands emit typed JSON Lines with a terminal success or error event, and stderr is advisory only. Explicit --output, --json, and --jq flags always take precedent. For humans, default output is the same as before, with a few exceptions: some success responses and dry-run notices have moved from stdout to stderr, partial failures in gcx resources get now exit 4 instead of 1, pull counts file-write failures instead of reporting success, and destructive logs adaptive, traces adaptive, and kg commands now prompt for confirmation, so scripts calling them need --force or --yes.

4. gcx reports anonymous usage statistics by default. gcx now reports the shape of usage: the command path, flag names, outcome, and duration. Identifiable information such as positional argument values, flag values, URLs, stack names, and query content are never sent. The only identifier is a random per-installation ID. gcx prints a notice about usage statistics on first run. Find out more by reading the docs.

Why we’re changing it

We want v1.0,0 of gcx to be stable and clean, so we needed to get any known breaking changes in before we cut v1.0.0. We think the command renames make every command name understandable and predictable. The config file refactor will make it more convenient to authenticate to multiple contexts. The opt-out usage statistics will help us understand how our users use gcx, so we can make the product better.

What is not changing

Any command that is not in the rename list above is unchanged.

What to check before you upgrade

• If you have scripts, continuous integration (CI) jobs, aliases, runbooks, or agent prompts that invoke gcx, grep them for the old spellings in the table above and update to the new names before upgrading the binary. Old paths fail immediately as unknown commands.
• If you call gcx alert templates create, update, or apply, switch to gcx alert templates upsert and be aware it always was create-or-update: it will overwrite an existing template with the same name.
• If you script gcx assistant investigations approvals, todos, document, report, timeline, or regenerate-report, remove those calls; they are gone and have no replacement.
• If you script destructive gcx logs adaptive, gcx traces adaptive, or gcx kg delete commands, add --force or --yes; they now prompt for confirmation.
• If a script parses gcx stdout, re-test it after upgrading: some success messages and dry-run notices moved to stderr, and partial failures in gcx resources get now exit 4 instead of 1.
• If you use gcx config set in automation, update the paths to the literal form, for example gcx config set stacks.<name>.grafana.server <url>; the old context-relative paths return an error with the new path.
• If external tooling reads or writes the gcx config file directly, update it for the version: 1 format (named stacks and cloud entries referenced by contexts) before upgrading. Interactive use needs nothing: migration is automatic and writes a backup first.
• If your organisation’s policy requires opting out of usage reporting, set GCX_TELEMETRY=disabled or DO_NOT_TRACK=1 in your environment or CI images before rolling out the new binary; run GCX_TELEMETRY=log gcx <command> to inspect exactly what would be sent. Details: https://grafana.com/docs/grafana-cloud/gcx/anonymous-usage-statistics/
• If you installed the bundled agent skills, run gcx skills update after upgrading so the renamed agento11y* skills and removed explore-datasources skill are reflected in your agent’s skill set.
• Do all of the above before upgrading past v0.4.x; if you pin gcx in CI, upgrade a dev pipeline first and run your scripts against it.

What this means for you

The rename requires some updates on your end to SDK packages, any custom dashboards and alerts, and RBAC permissions: We’ve made it backwards-compatible wherever we could, and old names will keep working during a transition period (retirement scheduled for the end of October) so you can migrate on your own schedule.

For step-by-step instructions, see the migration guide.

Thanks for being part of this journey with us. If anything here causes friction or you need a hand, reach out — we’re happy to help.

Team members will come back with the team. Membership used to be managed through a separate TeamBinding object and was visible only to team administrators. Members will become part of the Team resource, under spec.members, and the /teams/{name}/members and /users/{name}/teams endpoints will read from there. Anything that reads a team will get its members in the same response.

External group mappings will come back with the team. This is an Enterprise feature. External group mappings used to be managed only through the legacy /api/teams/{uid}/groups endpoint and were visible only to team administrators. They will become part of the Team resource, under spec.externalGroups. The field may appear on any Team as an empty list, but will only be used with Grafana Enterprise.

One thing to update if you already use the groups endpoint. The /teams/{name}/groups endpoint will return a plain list of group names (externalGroups: [string]) instead of the previous list of {name, externalGroup} objects. If you have an integration that reads this endpoint, update it to handle the new response before the change reaches your instance.

What is not changing. This affects the new Team API only. The Grafana UI will work exactly as before. The legacy /api endpoints that the current UI relies on will be served by the new API under the hood, but will not return the new fields. The extra data will be returned only when you query the new Team API directly. There will be no visible change in the product interface.

Why we’re making this change. Team membership and external group mappings are core parts of a team’s definition. Keeping them on the Team resource makes the Team API the single source of truth, so anything that reads a team gets a complete and consistent picture instead of stitching together separate objects and endpoints.

What to check before this rolls out.

• If you consume /teams/{name}/groups, update your client to handle the new externalGroups: [string] response shape.
• After writing spec.externalGroups, read the values back from the server. Grafana normalizes them on save (trimmed, lowercased, sorted), so the stored form may differ from what you submitted.
• Member and external group data that was previously visible only to team administrators will become part of the Team resource. If you treat membership or group mappings as sensitive, review who can read Team resources in your instance.