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 1 day 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 16 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 9 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 10 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 28 days 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 20 days ago

Improve UX for resources shared across multiple CLI projects

Some customers have multiple CLI projects to segment their checks. For example, a customer monitoring Product A, B, and C might create a CLI project for each (if they’re in separate repos, they want to deploy them separately, etc.) However, these separate projects might use the same alert channels or status page. Our options now are not ideal: Deploy the shared resources via a separate CLI project. Then, use fromId() in each project to refer to the shared resources. This is the best option, but it can be cumbersome since we need to deploy the shared resources, grab the IDs for any that were created, plug them into the other projects, then deploy those. Create and manage them entirely from the website UI. Then, use fromId() in each project to refer to the shared resources. Not great, ideally all resources should be managed via the CLI. Re-create the shared resources in each project and accept the duplication. This is not ideal and makes it hard to keep those shared resources consistent. It’s also not plausible for something like a shared status page.

Laura Guo 2 months ago

1