Changelog
Follow up on the latest improvements and updates.
RSS
Synthetic checks can now be run once as a preview before saving, so you can verify the target, assertions, and expected response are correct before the check goes live and starts monitoring for real.
Check out the Monitors documentation for the general check-creation flow, and the individual pages for each monitor type's full field list.
Incident management and on-call have been rebuilt from the ground up, with schedules, smart routing, ack-aware escalation, and public status pages all built in.
- On-call schedules:Rotations now support layers, cadence, and time-of-day restrictions, with shift overrides and a "Who's on-call now" widget included.
- Smart routing rules:A visual AND/OR/NOT builder lets you route incidents by condition, with a test panel to confirm behavior before you enable it.
- Real escalation:Ack-aware steps retry or advance automatically, responders can set channel preferences across email, SMS, voice, Slack, MS Teams, webhook, Jira, and SNS, and every attempt is logged on the activity timeline.
- Built-in status pages:Incidents can be published straight to a public page, with support for a custom domain and branding.
- Friendly incident IDs:Incidents now get a per-workspace, prefixed ID (INC-1, INC-2, and so on) instead of a global number, shown everywhere from Slack to voice IVR.
- One routing system:Routing Rules now cover both alerts and incidents, and existing Notification Policies migrate automatically with no day-one change.
This should get incidents to the right person faster, with a real audit trail of what happened.
Check out the Incident Management documentation for full details.
Onboarding is now a five-step wizard that walks you through creating your organization, describing your stack (role, primary language, and where you run services), naming your workspace, sending your first event, and verifying ingestion.
- Setup steps tailored to your stack.The role, language, and deployment choices from step two determine a recommended install path in step four: OpenTelemetry, using either an agent or SDK, for Kubernetes, VMs, or mixed deployments, and the AWS Integration for serverless. This means new users are not choosing blindly from a generic list.
- No guessing whether it worked.The final step waits for a real signal, a trace, log, metric, or RUM event, and marks itself complete the moment one arrives.
- A checklist that doesn't disappear.Finishing the wizard takes you to the home page, where a Setup checklist drawer shows what's left: instrumenting an app, building a dashboard, creating an alert, wiring a notification channel, and inviting a teammate. Each row can hand off to the assistant if you'd rather be walked through it, and the checklist reopens anytime from the Setup pill in the header.
This should reduce first-run confusion and help teams reach value faster.
Check out the Setting Up KloudMate documentation for full details
KloudMate now includes a full
SLO (Service-Level Objective)
module, turning reliability into a measurable target instead of a rough sense of "usually fine." An SLO pairs a signal with a target and a time window, for example: "99% of requests complete under 300ms over the last 30 days." KloudMate evaluates it continuously against real traffic.Setting one up:
- Pick your signal, or SLI: error rate, latency, uptime, or a custom metric.
- Set a target percentage and a time window (1, 7, 30 days, or the calendar month).
- Preview projected compliance live, before you save anything.
Once it's live, KloudMate tracks:
- Current compliance against the target.
- Remaining error budget.
- Burn rate, the rate at which that budget is being consumed.
Burn-rate alerts can page the team before the budget runs out. Compliance reports can also be scheduled, so numbers reach stakeholders automatically instead of someone pulling them by hand.
Creating or editing an SLO needs workspace admin access; everyone else can view.
This should make it much easier to see whether a service is meeting its promised uptime or performance goals.
Check out the Reliability & SLOs documentation for full details
Firing alerts now correlate into groups by shared labels, like service, host, or region. A single alert group opens per issue instead of paging separately on every individual signal.
How a group behaves:
- The first signal to fire sets the group's title, fixed after that even if a higher-severity signal joins later
- New matching signals append to the same group instead of spawning a new one
- Groups survive restarts and deduplicate against recurring issues over time
What you see inside a group:
- Every firing instance, with its state and severity
- A full audit trail, covering opened, appended, silenced, notification dispatched, and resolved states
- Per-channel delivery outcomes, with direct links to where each notification landed (Slack thread, Jira ticket, KloudMate Incidents)
Routing rules decide whether alerts group at all, along which label, and which channel the group notifies. Admins can also click Suggest rules to get AI-proposed grouping rules based on recent alert traffic, each with a preview of how much noise it would have collapsed.
A group is marked resolved once everything underneath has been Normal for a configurable period. A re-occurrence within the configured rejoin window rejoins the same group instead of opening a fresh one, so flapping alerts don't prematurely close and reopen the group.
This should cut a lot of noise during a real outage, when one root cause can otherwise trip dozens of alerts within seconds.
Check out the Alert Groups and Routing Rules documentation for full details.
A new module for endpoint health: Rate, Errors, and Duration metrics for every HTTP and RPC endpoint your services handle.
What each row shows:
- A protocol badge (HTTP, gRPC, or Connect)
- Throughput, error rate, and p50/p95/p99 latency
- For HTTP: a full 2xx/3xx/4xx/5xx status breakdown
One detail worth knowing:
4xx responses count as client faults, not endpoint errors, so bad requests from callers don't make a healthy endpoint look broken. Only 5xx responses and error-marked spans count toward the error rate.Click any endpoint for time-series charts and its recent (or failed-only) traces, with a shareable link.
This should give endpoint-level visibility into which of your endpoints are slow, failing, or busy, without building a synthetic check for every route.
Check out the API Monitoring documentation for full details.
KloudMate now supports SAML-based single sign-on (OIDC is also available), so your team signs in through your own identity provider instead of a separate KloudMate password.
Setup, in order:
- Add a connection for your IdP (paste metadata XML, or enter the SSO URL, issuer, and certificate manually for SAML; discovery URL, client ID, and secret for OIDC)
- Give your IdP the KloudMate values it needs (the ACS URL, or KloudMate's downloadable SP metadata)
- Verify your company domain
- Choose a provisioning mode: invite-only, or just-in-time, with a role assigned to auto-provisioned users
Once enforced, members on a verified domain are routed to the identity provider automatically; no separate password to manage. The account owner always keeps password login as a fallback, so a broken IdP connection can't lock the team out.
Before you start:
you'll need to be the organization owner, be on a paid plan, and have admin access to your IdP and your domain's DNS records.
Check out the Settings → Single Sign-On (SSO) documentation for step-by-step guides per provider.
Alarm indicators now surface directly at the panel level, with a global alarms drawer that makes active issues easier to spot without switching context.
KloudMate now has a dedicated API Keys section under Settings. Teams can generate, view, and manage API keys from one place, making it easier to authenticate programmatic access to KloudMate without relying on workarounds.
Alert creation through the AI workflow and reusable alert templates reduce the amount of manual setup needed to get monitoring in place.
Load More
→