Feedback
Changelog

Share your product feedback!

Tell Checkly how they could make the product more useful to you.

Maintenance windows: option to match tags with AND instead of OR

Maintenance window tag matching is currently OR only: any check with at least one of the window's tags is included. Combining tags like cluster:abc-prod and location:eu pauses every check that has either tag, instead of only the checks that have both. Request: an option to require all selected tags to match (AND), similar to the existing AND operator for tag filtering on dashboards. Use case: scoping maintenance windows to a specific cluster + location combination from a release pipeline. Today the only workaround is creating a dedicated combined tag per window (e.g. mw-abc-eu), which doesn't scale when tags already encode cluster, environment, and location separately.

Paula Mallol 7 days ago

Setting alertEscalationPolicy on a group silently drops its alert channels

Checkly's CheckGroupV2 reference does document the mechanism, and I had not found it when I hit this: "If you want the group's alert settings to override check-level alert settings, you must set the alertEscalationPolicy. Otherwise, the alert settings of individual checks will be used, even if alertChannels is defined in your group." So this is not an undocumented behavior. Two narrower things are still true, and I think they are the actionable ones. The warning is written for a reader who WANTS the override. I set alertEscalationPolicy to get repeat notifications for a single-channel setup, and the override arrived as a side effect - so the sentence that would have saved me is addressed to someone with the opposite intent, and reads as not applying. And the dangerous state is documented nowhere: nothing on the page says what happens when alertEscalationPolicy is set and alertChannels is not. The docs explain how to obtain the override. Nothing explains standing in it having named no channel, which is the only configuration here that silences checks. Requests unchanged in substance, reordered by what would have helped: Warn at deploy time when a group has an escalation policy and no alert channels while its members carry direct subscriptions. Documentation cannot reach someone who does not know to look. Say it in the parameter description for alertEscalationPolicy itself, framed as a consequence rather than as an instruction for the reader who wants it. Render it in the dashboard. A group that overrides alerting and names no channel should not look identical to one that alerts normally.

Markus about 11 hours ago

board CLI · checkly login mints a new API key without revoking the one it replaces

Running checkly login again on an already-authenticated machine creates an additional API key rather than rotating the existing one. Nothing warns that the previous key is still live, and the CLI gives no way to list or revoke keys, so they accumulate silently and can only be found in the web UI. Request: either reuse the existing key, or revoke it on replacement, or at minimum print the fingerprint of the key being superseded and a pointer to where it can be revoked.

Markus about 22 hours ago

board Public API · No usage or quota endpoint

There is no endpoint that reports how much of a plan's allowance an account has consumed. Of the 138 paths in the public OpenAPI spec, none covers billing, usage or quota, and /v1/account-usage, /v1/usage, /v1/limits and /v1/subscriptions all return 404. The account object does carry freePlanQuotaHitNotificationSent, freePlanQuotaNotificationWarningSent and freePlanStoppedRunningChecksWarningSent, but those are free-plan notification flags and they are sticky — they record that an event happened once, not where the account stands now. On a paid plan they keep reporting a threshold crossed under the previous plan, which is worse than absent, because it reads like a current figure. So the only way to answer "how much of our allowance are we using?" is to enumerate every check, read its frequency, its location count and its runParallel setting, and derive the run rate by hand. We do exactly that, and it is fragile in a specific way: multiplying cadence by location count is wrong whenever runParallel is false, because the check is round-robin and one cycle costs one run rather than N. Getting that backwards moved our own estimate from 18% to 54% of the browser allowance, and only a separately observed 24-hour run count showed which was right. Request: GET /v1/usage returning runs consumed per check type for the current allowance period, the allowance, and the period boundaries. Everything needed to answer it exists on your side and is shown in the dashboard. Anyone managing checks as code is currently reimplementing your meter from configuration, and quietly getting it wrong.

Markus about 22 hours ago

board Public API · Alert channel subscriptions are not marked as actionable

Support confirmed that the subscriber count in the UI accounts for group alert overrides, while GET /v1/alert-channels returns every subscription in the database regardless of whether it would ever be actioned. In their words, those subscriptions "may or may not be actioned when an alert is fired, as these do not account for group override settings." That means the API cannot answer the only question a monitoring-as-code setup needs to ask: for this check, which channels would actually be notified right now? On our account the UI reads 14 of 14 checks, 0 of 1 group while the API returns 30 subscriptions for the same channel, and both are correct under their own definitions. Request: either an actionable boolean on each returned subscription, or a resolved endpoint such as GET /v1/checks/{id}/effective-alert-channels. Without one, a CLI-managed account can only verify what it stored, not what would be delivered — and those differ exactly when a group override is in play.

Markus about 22 hours ago

board Public API · No endpoint to test an alert channel

The UI has a "Test alert channel" button on the channel edit screen and it works. There is no API equivalent. Of the 138 paths in https://api.checklyhq.com/openapi.json, the entire alert-channel surface is GET/POST /v1/alert-channels, DELETE/GET/PUT /v1/alert-channels/{id}, PUT /v1/alert-channels/{id}/subscriptions, GET /v1/alert-notifications and GET /v1/check-alerts. I also tried POST /v1/alert-channels/{id}/test, /send-test, /v1/alert-channels/test and /v1/alert-notifications/test. All four return 404. Why it matters: storing a phone number and subscribing it to 30 checks proves neither that the number is correct nor that the carrier delivers. Until somebody clicks that button by hand, a typo in an E.164 number is indistinguishable from a working channel, and the moment it becomes distinguishable is the outage the channel exists for. A POST /v1/alert-channels/{id}/test would make that a deploy-time assertion instead of a human ritual.

Markus about 22 hours ago

Manage account-level settings using Monitoring as Code (CLI, TF, Pulumi)

Currently, users cannot manage account-level settings, like account runtime or global alert configurations, through Monitoring as Code (MaC). This means users need to go through the UI for these settings, and there’s no way to track or manage changes through code. It would be helpful if we could also manage global account settings using MaC.

Laura Guo 22 days ago

Feature request: native UDP-based protocol monitoring (STUN, TURN, SIP)

Summary Add native check types that can send a UDP protocol handshake and validate the response. Specifically a STUN Binding Request, a TURN Allocate, and a SIP OPTIONS or REGISTER. Problem Customers running VoIP, UCaaS, or any real-time media infrastructure need to know their STUN and TURN servers are actually answering at the protocol layer, not just that a socket is open. STUN is the NAT traversal lookup and TURN is the relay fallback when a direct media path can't be negotiated, so nearly every call depends on both being healthy. Today there's no way to monitor either natively in Checkly. What we can cover today, and where it falls short TCP checks confirm SIP signaling ports (5060, 5061) and the TURN TCP fallback (3478, 5349) are listening, but a listening socket proves nothing about protocol health: the service can be crashed, misconfigured, or holding a stale shared secret and still accept the connection. Browser checks with WebRTC exercise the full ICE negotiation end to end from a user seat, which is valuable but slow, expensive, and doesn't isolate which component failed. Heartbeats let a customer keep an external probe alive and alert on missed pings, which works but means they're still maintaining the script we're supposed to be replacing. DNS monitors use UDP under the hood but aren't exposed as a general prober. Traceroute diagnoses where packet loss lives but doesn't handshake either, so it's complementary rather than a substitute. Requested capability A UDP-capable check type where the user specifies host, port, and protocol (STUN, TURN, SIP), with assertions on response code and latency. TURN would need optional credential support for the Allocate.

Shawn Harris 15 days ago

Granular API Key Access for Setting Maintenance windows

Introduce a new access level or API key configuration in Checkly that allows setting maintenance windows without granting permissions to update or modify tests. This feature will enable better separation of access rights. Use Case: We have Projet Owner for example that can plan actions that will create disruption and we want that their are able to set a maintenance windows. However the minimal right is “Read & Write" and we don’t want they have the ability to edit. Another use case is to set the maintenance automatically in CI/CD through Service API Key without giving Read & Write Access. The current access level do not align with this requirement: Admin - Full access to create, update, and delete resources. Read & Write - Can create, update, and delete checks, alert settings, and maintenance windows. Read & Run - Can view all resources and trigger checks and tests, but cannot create, edit, or delete. Ideal for CI/CD pipelines that only need to run tests. Read Only - View-only access to all resources. Priority: This feature is critical for maintaining secure access controls while adhering to robust CI/CD practices. Benefits: Improved security by minimizing unnecessary write access in sensitive environments. Enhanced alignment with least privilege access principles. Better flexibility for integrating with CI/CD pipelines across different workflows. Thank you for considering this enhancement!

Dylan Feith 15 days ago

2

Add rendered webhook payload to sent alert logs for debugging

When testing out webhook alert channels, and using the handlebars templating, it is difficult to diagnose where issues in the template syntax might be because there does not appear to be a way to view what the ultimate payload was. At least being able to see that what the payload was in the alerts log would be helpful while developing new webhook alerts.

Joel Ramos about 1 month ago

1

Ability to add individual checks and groups to a maintenance window

Currently, we can only specify checks for maintenance windows using tags. Customers who only need to add a single check need to first tag that check, and then add it to the maintenance window. It would be helpful and a bit more convenient if we can specify certain checks/groups directly, without going through tags.

Laura Guo 26 days ago