Alert rules can now catch an instance that stops reporting entirely, not just one that crosses a threshold. Turn it on per rule, and KloudMate remembers every instance it's seen, then alerts if any of them goes silent.

An instance is a unique series identified by its labels; group a heartbeat by host_name, and you get one instance per host; group by serviceName + pod_name and you get one per pod. Each is tracked individually, with its own state, history, row on the Instances tab, and dismissal. It's off by default and opt-in per rule, so nothing changes for existing rules until you turn it on. It works with any datasource.

How it fires: an instance missing from query results moves through the normal alert lifecycle, Pending, then Firing, with the reason instance stopped reporting; last seen <timestamp>. It recovers automatically the moment it reports again. Roughly, it fires the query window plus the pending duration after the last data point, so the window should be several times your reporting interval; a 60-second heartbeat with a 60-second window will flap on one late data point; a 5-minute window absorbs the jitter.

Check out the Instance Absence Detection documentation for full details, including how it interacts with routing rules, folders, silences, and maintenance windows.

Kubernetes Monitoring now includes a Storage tab showing Persistent Volume Claims across your clusters, giving visibility into storage alongside your existing pod and node metrics.

Each row shows the Persistent Volume name, cluster, status, claim name, storage class, and capacity. Filter by Persistent Volume type, cluster, or status, or search by name.

This should make storage issues visible in the same place you already check pod and node health, instead of needing kubectl to see what's bound, how much capacity is used, or what's stuck pending.

Check out the Kubernetes Monitoring documentation for full details.

Sharing a dashboard now works the same way no matter where you start it; sharing from the dashboard list and sharing from an individual dashboard page both open the same Share dialog with both options available, instead of the list forcing an immediate JSON copy while the dashboard page only offered a public link.

Check out the Dashboard Details documentation for how sharing works.

Correlates related alerts into a single incident instead of flooding the team with separate alarms. It's opt-in per routing rule: switch a rule's Alert grouping setting to , and the engine takes over from there, learning which alerts tend to fire together over time. No grouping keys to set.

When multiple alerts fire close together, the engine works down a signal ladder to decide whether, and why, they belong together, checked in order:

Each group shows its members and a reason. You can thumbs-up or thumbs-down a grouping decision; a single thumbs-down is a one-off override, but a second person flagging the same pairing stops it from grouping that way again. Groups link directly into for investigation.

Check out Alert Grouping: Static or Auto (AI) and How Alert Grouping Works for full details.

When a panel was built using a custom data source variable, reopening it for editing showed the data source correctly selected but left the query field empty, even though a valid query had been saved. This made a working panel look unconfigured and risked someone overwriting it with a blank query on save. Both the data source and the previously saved query now reload correctly in edit mode.

When building an alert query with two or more dimensions (e.g., + ), the preview concatenated the labels into one unreadable string instead of showing them separately, also affecting Dashboards and the Explore page. This made it impossible to verify a multi-dimension query was configured correctly before saving. Labels now display cleanly and separately per dimension.

Clicking Download on any report failed silently, with a blocked CORS request in the browser network log, meaning no reports could be exported from the UI at all (emailing the report was the only workaround). The cross-origin request issue is fixed, and downloads now complete normally.

You can now leave an organization yourself instead of asking the owner to remove you, a useful cleanup if you've accumulated memberships in orgs or workspaces you no longer use.

Non-owners can leave at any time

Owners must transfer ownership to another member first; an organization always needs at least one owner, so the leave action stays unavailable until ownership is transferred

Find it under Settings → Organization → Danger Zone. Leaving removes your access to the organization and every workspace and data set associated with it.

Check out the Organization documentation for full details.

A new Availability Report type has been added: detailed availability statistics for a group of alert rules over a selected time range, so teams can generate availability-focused reporting directly instead of piecing it together from other report types.

Each report shows its Source, Schedule, Format, and Active status, with buttons to send it immediately, view previously generated reports, or edit it, plus a time range control. Above the alert table, a summary rolls up overall availability, alert rule count, total triggers, cumulative down duration, and affected instances across the whole set. Two tabs break it down further: Alert rules (one row per rule, with availability %, trigger count, down duration, instances, and labels) and Instances (the same data per affected instance instead of per rule).

Worth noting: SLA Target, SLA Achieved, and SLA Status columns are no longer part of this report; that tracking now lives in SLOs, with the SLO Compliance report as the scheduled rollup equivalent.

Check out the Availability Report documentation for full details.

KloudMate now includes a Network Monitoring module: watch the routers, switches, firewalls, access points, and PDUs that carry your traffic, all from one Network page. A Linux or Docker KloudMate Agent does the polling, so nothing installs on the devices themselves (Kubernetes agents can't run this).

, via a six-step wizard (agent, targets, credentials, profile, tags, review) or Discover devices, which scans IP ranges and monitors whatever answers. Vendor profiles auto-detect for Cisco, Juniper, Arista, HPE, Aruba, Dell, Fortinet, Palo Alto, MikroTik, F5, APC, and more

for sites that can't speak SNMP: a gateway probe (local network) plus an internet probe (ISP link), read together to tell you where a fault actually is

via NetFlow, IPFIX, or sFlow, breaking traffic down by application (HTTPS, DNS, database, etc.), with optional raw flow logs for a top-talkers view

the Overview shows health tiles (devices down, uplinks down, BGP/VRF down, errored interfaces), a worst-first problems feed, and a status board groupable by site, role, or vendor.

A status is deliberately distinct from ; the former means the poller itself went quiet, the latter means the agent polled and got no answer, so a banner names the affected poller instead of marking every device under it as down.

Turn on optional capabilities (BGP peers, MPLS L3VPN, LLDP neighbours, IP SLA) for routers and layer-3 devices; LLDP data feeds a tab that draws the link map between monitored devices.

Check out the Network Monitoring documentation for full details

KloudMate now includes a Profiling module: continuous CPU and memory profiling that turns sampled data into an interactive flame graph, so you can go from "this service is slow" to a specific function and line number, without attaching a debugger or shipping a new build.

a grid of every service reporting a given profile type, with a peak value and mini trend chart per card, your entry point

pick one service and see every type it reports (CPU, heap, goroutines, etc.) side by side

break a service's profile down by resource attributes (region, pod, version) to isolate where a spike is coming from

the actual hotspot-finding view, zoomable, with sandwich mode (see a function's callers and callees), a sortable function table, and an Ask AI button that hands the top 10 functions by self time to the KloudMate Assistant

compare two time windows of the same service, merged (one tree colored by change) or side by side, the view for "did that deploy make things better or worse?"

KloudMate accepts OpenTelemetry Profiles or the Pyroscope protocol, with dedicated SDK guides for Go, Java, Python, Node.js, Ruby, .NET, and Rust.

Check out the Profiling documentation for full details, including per-language SDK setup guides.

The KloudMate agent has been rebuilt to reduce the manual setup previously required to start collecting database, log, and APM telemetry, replacing hand-written collector configuration with wizards and per-service toggles.

Automatic from install, no config needed: service/runtime/database discovery, host metrics and logs, and eBPF monitoring (RED metrics, network service map, Database Activity Monitoring, trace-context propagation), all with no code changes.

For automated rollouts, an advanced autonomous mode instruments every eligible service and auto-wires reachable web servers with no per-service toggles.

Check out the KloudMate Agent documentation for full details.