💡 For general support requests and bug reports, please go to <a href="https://checklyhq.com/support">checklyhq.com/support</a>
Is your feature request related to a problem? Please describe.
My eyes at night. It hurz
Describe the solution you'd like
Dark mode.
Describe alternatives you've considered
Wearing sunglasses looking at Checkly, at night.
Additional context
🌚
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/124">https://github.com/checkly/public-roadmap/issues/124</a>

In Review

General

Dark. Mode.

Tim Nolet

Summary:Allow users to customise or override the NPM dependencies within the Checkly runtime environment.Description:Currently, users are restricted to a set list of packages and versions in the Checkly runtime, which may not cover all the specific use cases or compatibility issues they encounter. As a Checkly user, I need to be able to dynamically use packages in my own runtime. I process dependency updates in projects regularly to use the latest versions for new features and security updates.

Runtimes

Customisation of NPM Dependencies

Alex Noyes

It would be great to be able to run checks at specific times (like a cron job schedule), as we have an API that publishes certain customer-critical data daily at specific times. So instead of every X minutes which can be any time depending on when the check is first created, we would be able to run reliably at specific times.

Scheduling

Scheduled checks at specific times

Yawar Amin

💡 For general support requests and bug reports, please go to <a href="https://checklyhq.com/support">checklyhq.com/support</a>
Is your feature request related to a problem? Please describe.
We have a time out of apis defined at our load balancer level as 60 sec, checkly times out the request at 30 sec max with which we are not able to identify if the system is not responding or checkly servers not able to communicate with our servers.
Describe the solution you'd like
Providing an option of custom timeout (maximum configurable to 100 sec)
Describe alternatives you've considered
NA for now
Additional context
NA
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/207">https://github.com/checkly/public-roadmap/issues/207</a>

Increase Response time limit for checks

We use Checkly statistics to monitor our uptime %. Sometimes we have failures that are false positives (since there was a bug in the test or specific to the test environment, and not in production, or just things didn't really break). We don't want to count those failures as downtime, hopefully with adding a note to why. Thanks!

Insights

Mark/Delete failures as false-positive

Amir Jaron

Currently, time-based escalation cannot be set to less than 5 minutes. In most cases, this threshold is pretty high for sensitive API checks. I'd highly appreciate it if you could make it more flexible. <img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/1714668070085..png"><pre><code> time_based_escalation {
 minutes_failing_threshold = 5 // (TIME_BASED escalation only) after how many minutes spent in failing state to send an alert ()
 }</code></pre>As of now, it can be set to <code>5, 10, 15, 30 minutes</code> The requested thresholds are, <code>1</code>, <code>2</code>, <code>3</code>, <code>4</code>, <code>5 minutes</code> <code>Reference: </code><a target="_blank" rel="noopener noreferrer nofollow" class="text-indigo-500 dark:text-indigo-300 cursor-pointer" href="https://www.checklyhq.com/docs/terraform-provider/alerting/#alert-settings">https://www.checklyhq.com/docs/terraform-provider/alerting/#alert-settings</a>

Alerting

Support for more flexible thresholds in Alerts escalations

Mehmet Sever

We have a use case where we're interested in using Checkly to monitor a WebRTC application. For this application, cameras and microphones are a critical part of the experience. Fortunately, chromium has fake media devices which can be used in Playwright. It would be great to be able to access these from within Checkly tests.

Browser Checks

Access to fake media devices

Brian Hill

💡 For general support requests and bug reports, please go to <a href="https://checklyhq.com/support">checklyhq.com/support</a>
Is your feature request related to a problem? Please describe.
We are not able to access Lighthouse report details from the API when executing browser checks.
Describe the solution you'd like
We would like to be able to access Lighthouse report details so we can fail tests when performance degrades.
Describe alternatives you've considered
Some data is available thru the performance.getEntriesByName object, we are using this as a workaround.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/79">https://github.com/checkly/public-roadmap/issues/79</a>

Check Types

Access to the complete Lighthouse metrics

Hey Checkly team :wave: Currently if we have multiple checks under a group and alerting is setup to be routed to tools like PagerDuty or OpsGenie, there are times where we'll be bombarded with alerts. This happens when the check dependencies all share the same downstream call, and that downstream call is problematic. If its possible to aggregate the alerts by the group, this would drastically reduce the alerting noise if we get into another instance where all checks under a group starts to fail. I'm not sure if this is possible due to a limitation from OpsGenie, PagerDuty etc.But the end goal would be to send a single alert that references the group, and additional metadata is added which specifies which check is failing, as opposed to each check being an individual alert.

Aggregate alerts under a group

Alex Panayi

💡 For general support requests and bug reports, please go to <a href="https://checklyhq.com/support">checklyhq.com/support</a>
Is your feature request related to a problem? Please describe.
Instead of alerting on a single request being slow, I'd like to alert if the average or p95 time exceeds a limit.
Describe the solution you'd like
When setting Assertions, I would like to be able to chose "average response time" or "p95 response time" as the Property value for a Response Time check.
Describe alternatives you've considered
Checking the dashboard manually? I'm not sure what other options there are.
Additional context
A single slow request may not be worth an alert. But several slow requests will raise our average/p95 response times and are worth investigating.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/224">https://github.com/checkly/public-roadmap/issues/224</a>

Alerting based on p99 response time

I want to check the core metrics and correctness of my DNS and DNS records. A DNS check should be able to: <ul><li>monitor the response time of a DNS query.</li><li>assert the corrects values and existence of specific DNS records. </li></ul>

Planned

DNS checks

💡 For general support requests and bug reports, please go to <a href="https://checklyhq.com/support">checklyhq.com/support</a>
Is your feature request related to a problem? Please describe.
We do http monitoring but we have some api's that are not http but are at tcp level.
Having monitoring for tcp connections basic check on URL and any Port is great. 
Can integrate tls as well. 
Describe the solution you'd like
as part of addition of api checks, we can add tcp as an option in the drop down. 
Describe alternatives you've considered
using datadog right now .
Additional context
Add any other context or screenshots about the feature request here.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/96">https://github.com/checkly/public-roadmap/issues/96</a>

add ability for tcp and icmp checks.

HI Checkly Team, We have lots of Checkly accounts created under our org and are looking to get more in the future. We have a tooling suite for creating checks on Checkly and its pretty much streamlined except for the account creation part. We are looking to streamline account creations as well, as the current process is to email our Checkly representative and that has a turn-around time of ~24hours. We are looking to have this automated via API, preferably get it to be a Terraform resource. We are currently using terraform to create Checkly resources, but whatever way would be faster to get this to become a reality would be great

Auth / Access / Roles

Automated Account Creation

Giancarlo

To truly unite E2E testing and monitoring, Checkly CLI has to support the global configuration defined in playwright.config.ts, so that it can be used in both scenarios.playwright.config.ts is very useful to handle stuff like:<ul><li>Common viewport for tests</li><li>Common setup, teardown for tests</li><li>Common storageState for tests</li><li>Turn screenshot, trace, video on/off</li><li>And all the other useful playwright.config features that make playwright awesome</li></ul>

In Progress

Global playwright.config.ts support (viewport, setup, teardown, storageState ...)

Younes Jallouli

Any check that requires auth / credentials that expire needs to fetch these credentials on every check run. While this is the safest way to make sure checks are authenticated, it creates friction: - extra runtime in a browser check or setup script. - extra load on any authentication endpoint. - waste of general cloud resource. A user should be able to store tokens securely in a check run and fetch or revalidate the credentials when or before they expire.

Store tokens and other credentials across check runs

Describe the solution you'd like
For a CRUD API set, it makes sense to test these in a multi-step sequence. For example, to do a POST to create an object, assert that it was created in the response, then POST to delete the object and assert the response.
Describe alternatives you've considered
Could potentially do this in setup/teardown scripts, although then it is less clear in the monitoring.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/46">https://github.com/checkly/public-roadmap/issues/46</a>

Completed

API Checks

Multi-step API check

💡 For general support requests and bug reports, please go to <a target="_blank" rel="noopener noreferrer nofollow" class="text-indigo-500 dark:text-indigo-300 cursor-pointer text-indigo-500 dark:text-indigo-300 cursor-pointer" href="https://checklyhq.com/support">checklyhq.com/support</a>Is your feature request related to a problem? Please describe.<ul><li>I would like to browser-checks for our internal tools (Blocked IPs, Some in private network). Which is not open public? I don't have much control on web server level to these tools. Currently, there is no way to have checks to these.</li></ul>Documentation suggesting whitelisting AWS-IPs doesn't make sense, this basically means opening to internet.Describe the solution you'd like<ul><li>Static IP sets. I don't know how your infrastructure looks like, if it's possible to run check runners behind few NATs. We can have IPs sets which can be whitelisted in our LB/firewalls. Any ways these IPs can be changed if your infra needs some update, So an API endpoint which list current IPs help more, to automate IP whitelisting.</li><li>If NAT is not a possible solution, having an open AWS SNS, Even-Bridge some sort where I can subscribe in our AWS accounts to load new IPs to SGs using lambda.</li><li>Having private-link or VPC peer to our VPC. This can help to have checks on private network itself.original GH issue link <a target="_blank" rel="noopener noreferrer nofollow" class="text-indigo-500 dark:text-indigo-300 cursor-pointer text-indigo-500 dark:text-indigo-300 cursor-pointer" href="https://github.com/checkly/public-roadmap/issues/154">https://github.com/checkly/public-roadmap/issues/154</a></li></ul>

Static IPs

The current retry strategy for all checks is fairly limited. We want to expand the possibilities for retrying with two options: - same region: right now, retries are always scheduled on a different region than the original attempt. This is not ideal for geo-fenced checks or region-aware websites rendering different content for different regions. - backoff strategies: we want to enable multiple retries according to a strategy the user can define: linear or exponential so the target system has more time to recover from an initial failure.

Smarter retries strategies: same region and backoff

Is your feature request related to a problem? Please describe. I have a particular use case for toHaveScreenshot in that my Checkly tests goes through our UI to generate a PDF export of a particular page that you're on. I'd love to be able to compare a screenshot of the PDF generated to a snapshot, as it's impossible to run typical assertions on the information shown in PDFs.Describe the solution you'd like I understand that Checkly agents run in an isolated environment for each test. However, toHaveScreenshot could be supported in a way similar to Buildkite in how it allows you to manage artifacts between builds and build steps, it would be cool if the Checkly agent could detect snapshots generated from toHaveScreenshot, store them somewhere, and then pull them down for the next test to verify against. This could be automatic, or something that the test does, wherer you test can import some kind of Checkly npm package that exports some functions to do these particular tasks.Describe alternatives you've considered What I'm trying to achieve here I can write this code myself. I.e i can store the screenshot snapshots in S3 at the end of my test and write them to disk when the test starts again but that's not ideal at scale if I need to do this in multiple tests. There are visual comparison libraries out there but they aren't in the Checkly runtimes. Adding some kind of visual comparison npm package to the runtimes would suffice too!!!original GH issue link <a target="_blank" rel="noopener noreferrer nofollow" class="text-indigo-500 dark:text-indigo-300 cursor-pointer text-indigo-500 dark:text-indigo-300 cursor-pointer" href="https://github.com/checkly/public-roadmap/issues/282">https://github.com/checkly/public-roadmap/issues/282</a>

Support for `toHaveScreenshot` / visual regression testing

One of our checks was failing intermittently when running from one location, so it was not flagged under failures. We only came across these failed runs when looking into the monitoring results of that particular check. <img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/1695816229542.png">Based on the above monitoring results, we see a clear degradation as whenever the check runs from a particular location first, it fails. It would be great if such failed runs are flagged as degradation of the test as, currently, there is no way for us to be aware of the situation unless we drill into the monitoring results.

Failed runs classified as & reported as degradations

Krishna

As a Checkly administrator I would like to create private dashboards (View only TV mode style) and share them with third parties using individual username/password or other secure methods that ensure the dashboards are only viewable by authorised users.
These users should not count towards the "employee or user" count for billing but may be bundled as part of billing packages.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/23">https://github.com/checkly/public-roadmap/issues/23</a>

Status Pages

Private Dashboards

<h1 id="problem">Problem</h1>
Checkly currently runs your checks in a round-robin fashion, cycling through the locations you have selected for your checks. This is an "easy to reason about" system. 
However, for global infrastructure and apps like CDNs, Anycast-type systems, or any app that resolves one domain to region specific endpoint this is not great as a failing check that fails in one specific region, will resolve if the next region is healthy. The result is that the check does not indicate of one specific region is having problems, whereas others are fine.
<h1 id="proposedsolution">Proposed Solution</h1>
<ul>
<li>Checkly should have the option to schedule checks parallel for all regions, instead of round-robin.</li>
<li>The status of a check should be able to have a "partial" or "regional" outage.</li>
<li>Checkly should be able to alert on regional outages
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/198">https://github.com/checkly/public-roadmap/issues/198</a></li>
</ul>

Parallel Check Runs

Is your feature request related to a problem? Please describe.
Uptime monitoring can be divided into roughly 2 categories
Remote Checks 
This is currently what checkly focuses on and is a simple check that is made from a remote server on a fixed interval and if any of these checks fail notification is sent.
Deadmanswitches
These are actually the inverse, these are checks that are generated from the client and if any of these fail to report notification is sent.
These are insanely valuable for background processing or database backups where you need to verify that the job successfully completed. 
See https://en.wikipedia.org/wiki/Deadman%27sswitch 
Describe the solution you'd like
I would love deadman switch type check added to checkly so we can consolidate our monitoring offering. 
Describe alternatives you've considered
<ul>
<li>http://healthchecks.io/ (open source self-hosted version available)</li>
<li>https://deadmanssnitch.com/ </li>
<li>https://docs.opsgenie.com/docs/heartbeat-monitoring </li>
</ul>
Additional context
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/72">https://github.com/checkly/public-roadmap/issues/72</a>

Deadmans Switch type checks

Hello Checkly Team,I recently reached out regarding the possibility of implementing retries for test sessions in a manner similar to what we can do with monitoring checks. This feature would be incredibly beneficial for users who need to ensure reliability and effectiveness in their test strategies, especially in environments where transient issues might cause test failures that don't necessarily indicate a problem with the tested application itself.The ability to configure retries for test sessions would not only add a layer of robustness to testing strategies but also align the capabilities of test sessions more closely with the monitoring checks feature. This consistency across Checkly's platform would enhance the user experience, making test management more intuitive and efficient.Implementing a retry mechanism could include customizable options such as:<ul><li>The number of retry attempts before a test is marked as failed.</li><li>The interval between retries.</li><li>Conditions under which a retry should be triggered (e.g., specific error types or failure scenarios).</li></ul>Such a feature would be a significant improvement for teams looking to minimize the impact of flaky tests and transient errors, ensuring more accurate monitoring and alerting based on the true state of their applications and services.I believe this enhancement would greatly benefit many Checkly users, providing them with more control over their testing processes and improving the reliability of their test outcomes. I encourage other users who see the value in this feature to upvote this request, bringing it to the attention of the Product Team.Thank you for considering this suggestion. I look forward to any updates on its potential implementation and am happy to provide further input or participate in beta testing if needed.

Implement Test Session Retries Similar to Monitoring Checks

Jiang Liu

Heartbeats should also support the POST method and not just GET. Also, it will be super valuable to be able to add assertions on the POST payload body.

Heartbeat Checks

Heartbeat to support POST payload validation

Is your feature request related to a problem? Please describe.
<ol>
<li>I want to allow users to subscribe to status updates from our service.</li>
<li>I want to subscribe to Checkly's status so I know when the service is down or degraded, because:</li>
<li>This might impact how our customers see the status or our service;</li>
<li>We want to know that our services might not be monitored for the duration of the inciden.</li>
</ol>
Describe the solution you'd like
An option on Checkly's status page allowing users to subscribe to updates.
Ideally, they would be able to choose between multiple ways to get notifications, like RSS/Atom feeds, email, Slack, maybe even webhook - see example from <a href="https://www.githubstatus.com/#">Github's status page</a>:
<img alt="image" src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/20231002171230917165.png" width="418"/>
Which is similar to <a href="https://status.sentry.io/">Sentry's</a> - it seems they use Atlassian Status Page.
I see #297 asks for a specific type of update, but I'd like to have more options than just email.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/304">https://github.com/checkly/public-roadmap/issues/304</a>

Subscribe to status updates

Is your feature request related to a problem? Please describe.
we're very happy with the new dashboards, which have become integral to our communication (https://status.qfield.cloud/). There is, unfortunately, a big shortcoming for us. 
A planned maintenance window is only visible once it becomes active.
<img alt="image" src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/20231002171231191958.png"/>
To really become fully operational as a status page, these should be visible ahead of time.
Describe the solution you'd like
show planned maintenance as non-active planned incidents
Describe alternatives you've considered
A minimal solution could be to show planned maintenance as in the admin dashboard
<img alt="image" src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/20231002171231353164.png"/>
Additional context
potentially part of #242 and #240 and #65
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/302">https://github.com/checkly/public-roadmap/issues/302</a>

Show planned maintenance windows in dashboard

Right now you can see up to 30 days back. It will be nice to have a 30,90,180,365 days option as we have a guaranteed SLA calculated per year.

Uptime % history on dashboards

It doesn’t seem like there’s any way to hide disabled checks from the dashboard. <img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/1691764909873.png">

No way to hide disabled checks

Jonathan Canales

We're setting up a number of in-depth checks in checkly which are great for internal monitoring and metrics.For these to be useful in a dashboard however, we'd ideally be able to group them, and/or summarise them.One potential way to do this is using tags, or with a tag mapping.So for example, we might have the following tests + tags:<ul><li>Test Login (scope-public, service-website, component-login)</li><li>Test User Creation (scope-public, service-users, component-management)</li><li>Test User Emails (scope-public, service-users, component-notification)</li><li>Test Account Emails (scope-public, service-account, component-notification)</li></ul>When setting up the dashboard, we might choose to use the summarized view. To do so, we set up the following:<ul><li>Dashboard filter: scope-public</li></ul><ul><li>Label: Notifications, tag: component-notification</li><li>Label: Users, tag: service-users</li><li>Label: Website, tag: service-website</li></ul>The dashboard would then show only 3 rows: Notifications, Users and Website. Each of these would show the result of all checks that matched the existing Dashboard filter functionality, but would be grouped based on the Labels we set up. In some cases, a check might fall into 2 or more Labels; that's ok, the metrics should be used in all matching Labels. If a test doesn't match any mapping, then it should be displayed as-is.This allows the checks to be far more useful for internal alerting/reporting, but far more approachable for public viewing An alternative would be a version of the Dashboards that doesn't use filters at all, but instead just lets you create Labels and assign existing tests to those Labels explicitly.

Allow grouping / summarizing of checks in Dashboards

Peter Dolkens

Is your feature request related to a problem? Please describe.
Being a relatively small team, adding an incident in the dashboard, is not usually the first thing that happens in our incident response. In addition, discovery and response times will vary. 
This means that it might go several minutes from a problem arises (and is noticable by end users), to when we are publishing an incident on our Checkly Dashboard.
This is unfortunate during an incident (but usually mitigated by visible failing check ), but directly misleading in the historical overview, where the incident will seem (potentially much) shorter than it really was. This impacts user trust.
Describe the solution you'd like
When editing a incident status update, I should be able to update the timestamp of that update.
Describe alternatives you've considered
You might have a separate date field for published timestamp, but I think that will be more confusing, both for the incident manager and the end users.
Additional context
This is a feature I used a lot in a previous gig, where we used statuspage.io (which you are quickly surpassing in other ways! kudos!)
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/278">https://github.com/checkly/public-roadmap/issues/278</a>