Feedback
Changelog

Share your product feedback!

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

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 10 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 3 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 4 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 22 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 14 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 about 2 months ago

1

Feature Request: Multiple Export Endpoints for Traces

Problem The Traces export UI only allows a single endpoint URL + auth header set. Customers whose observability infrastructure is separated by region need to send exported spans to a different endpoint per region, which isn't possible natively today. Workaround (confirmed working) Point Checkly's trace export at a self-hosted OpenTelemetry Collector, then configure multiple destinations downstream — multiple exporters for duplication, or a routing connector keyed off a region attribute for true per-region routing. This works but requires customers to run and maintain extra collector infrastructure. Proposed Solution Native support in the Traces export config for multiple endpoints, ideally with region- (or attribute-) based routing so spans reach the correct destination rather than being duplicated to all. A simpler v1 could support multiple endpoints with duplication; attribute-based routing is the higher-value version. Impact Removes the need for region-separated customers to run their own collector just for fan-out/routing, and lowers the barrier to adopting trace export for enterprise customers with multi-region observability stacks.

Shawn Harris 2 months ago