Changelog

⚠️ Action required (API users) - migrate off the v1 alert history endpoints

The v1 alert history endpoints are deprecated and will be removed in an upcoming release to address a security vulnerability affecting them, tracked at #11747. Once removed, requests to the v1 endpoints will return 404 Not Found.

If you call any of the POST /api/v1/rules/{id}/history/stats, /timeline, /top_contributors or /overall_status, for example in scripts, integrations, or dashboards built on the API, move to the v2 GET /api/v2/rules/{id}/history/* equivalents. They return the same data, with some request and response schema changes (v2 uses query parameters instead of a JSON payload, cursor-based pagination, and a filterExpression string in place of the v1 filters object).

The migration guide covers the full endpoint mapping and every request/response change. Authentication and authorization are unchanged — the same API key and Viewer access continue to work.

A revamped Infrastructure Monitoring for investigating Kubernetes issues

Infrastructure Monitoring has been rebuilt to make investigating Kubernetes issues faster and clearer, with richer tables, redesigned entity pages, and query-builder search across the whole module.

Search with expressions: you can now search across Infrastructure Monitoring using the query builder, the same way you already do in Logs and Traces. Additionally, quick filters now show only the values relevant to your current filter, so filtering by a namespace narrows the node list to that namespace.

More information at a glance: resource lists now include status columns with counts, more columns per resource (volumes show inodes, age and restart counts on pods), and status filtering for hosts, plus onboarding checks that flag any required attributes you're missing.

Redesigned entity pages: clusters and namespaces open with a quick workload overview, Deployments, Jobs, DaemonSets, and StatefulSets get a new Pod Metrics tab, and any chart can be sent to the Metrics Explorer with the compass icon in its title.

Customization and inline docs: control table font size, lines per row, and visible columns, and hover the info icon on any column or chart to learn what it means.

Scope telemetry access by ingestion key ID

Building on the public beta release of fine-grained access control, you can now create custom roles that restrict which telemetry a user can query, down to the data sent with a specific ingestion key. This is useful when each team ingests with its own key and should only see its own traces, metrics, and logs, or if you wish to create scoped user roles within individual teams.

Create a custom role, scope its telemetry read access to one or more ingestion key IDs, and assign it in place of the user's managed role (signoz-admin, signoz-editor, signoz-viewer). Queries that pin that ingestion key ID are allowed, but anything broader is denied. You'll find this under Settings → Roles.

See the telemetry access guide to get started, or the reference for the full evaluation rules.

Available in beta to Cloud and Self-Hosted Enterprise users. Note that the roles are additive, so a scoped role must replace a user's managed role to actually restrict access, and role assignment remains admin-only.