Improved

Fixed

checkly

In Review

Planned

In Progress

Completed

Rejected

Status Pages

API Checks

Browser Checks

Check Types

Alerting

Groups

Auth / Access / Roles

Scheduling

General

Runtimes

Insights

Checkly Agent

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

Have something to say?

Tell us how we could make the product more useful for you.

Share your feedback

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>

Multi-step API check

💡 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>

Access to the complete Lighthouse metrics

At the moment there is only a percentage about a down time. I'd like to see the absolute duration of a downtime.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/280">https://github.com/checkly/public-roadmap/issues/280</a>

Absolute duration of downtimes

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 src="https://user-images.githubusercontent.com/233663/231202305-4ae356b8-26d8-4c81-aa6a-d1c97572b138.png" alt="image" />
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 src="https://user-images.githubusercontent.com/233663/231202514-e81739c7-a243-40e1-853b-55ebad92a358.png" alt="image" />
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

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 width="418" alt="image" src="https://user-images.githubusercontent.com/2132564/235011867-a4d2119d-df2d-491d-81e3-20fbd0e45f42.png">
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

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>

Private Dashboards

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

Is your feature request related to a problem? Please describe.
We're building a GraphQL Endpoint.
Checkly allows using GraphQL Queries in API Tests. https://www.checklyhq.com/docs/api-checks/request-settings/
But in Checkly's UI, can't using GraphQL Variables.
Describe the solution you'd like
Add a form to write GraphQL Variables.
Describe alternatives you've considered
Using JSON body type as a workaround. But, this is painful for me.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/73">https://github.com/checkly/public-roadmap/issues/73</a>

Support GraphQL Variables

Is your feature request related to a problem? Please describe.
Our company uses "Design-first approach" regarding APIs so we always define OpenAPI spec before doing any coding. 
Because of that we are maximising benefits from having this spec, like validating data in servers, generating clients etc…
You already have basic support for OpenAPI specs, but you only use routes. You don't use schema in any way.
Describe the solution you'd like
When importing OpenAPI spec, not only generate test routes, but also generate JSON schema that will be used to do assertions without any user input.
Describe alternatives you've considered
At least allow to define general data types for assertions :) So I could easily define "this field should be string with min-length of 2 characters" or "this should be floating point number" instead of giving exact value.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/75">https://github.com/checkly/public-roadmap/issues/75</a>

Support JSON schema

💡 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.

Just wondering if you would consider implementing an alert rule for "x failures in y minutes"?
My reason here is that our applications are load balanced between web servers, so it might fail once on a bad server, but the next check is OK because it hits a different server.
We'd like to see if theres the option to have a "X fails in Y minutes" so that we can filter out the random failures (Alert fatigue), and only get alerted when there's frequent failures.
Thanks!
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/122">https://github.com/checkly/public-roadmap/issues/122</a>

Alert Enhancement: x failures in y minutes

💡 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>

Dark. Mode.

Currently you can only set every minute, every 5, 10, 15, 30, 60 minutes, 12 hours or 24 hours. This is suitable for many cases, but many tests are needed much more often during the day than at night, when there are hardly any customers and we cannot react.
I would like to set some tests to run every hour from 8am to 8pm, for example, but only every 4 hours or something like that from 8pm to 8am. 
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/125">https://github.com/checkly/public-roadmap/issues/125</a>

Better adjustable time periods for tests

💡 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.
<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 href="https://github.com/checkly/public-roadmap/issues/154">https://github.com/checkly/public-roadmap/issues/154</a></li>
</ul>

Static IPs for browser 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.
playwright is nice but still a lot of work if all you want to make sure your website is live.
instead, it would be much easier to take a snapshot/screenshot (typically steady-state, not changing website) and code the check to compare it, like https://playwright.dev/docs/test-snapshots
Describe the solution you'd like
above.
Describe alternatives you've considered
perhaps a no-code option just for a screen diff. doesn't have to use playwright
Additional context
toMatchSnapshot? The issue is that it's part of @playwright/test which Checkly doesn't support at the moment. You can see however that it isn't completely out of our radar https://github.com/checkly/public-roadmap/issues/167.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/179">https://github.com/checkly/public-roadmap/issues/179</a>

Support lightweight web change detection with snapshot match

Is your feature request related to a problem? Please describe.
If a site being monitored is behind a load balancer(which is like all sites now) it is possible that only 1 node of N would be failing the check once in a while. 
Checkly would be sending and clearing alert in this case not allowing the support team to react as the incident would not stay open
for long. 
So Problem statement: checkly is not able to have an open alert for a check that frequently succeedes and sometimes fails. It can only have an open alert for a check that is failing at this moment. 
Describe the solution you'd like
I want checkly to inform us via alert in cases when a site has an infrequent failure which repeats after some number of checks. 
In the alert set up, where rules are defined have a radiobutton for a different way of detecting a failure.
Let's call that "flapping detection logic" (please have a better name for it) :)
Idea of such check is: 
<ul>
<li>Mandatory: Ask user to provide time duration (should always be longer then the frequency of the check) for example 10 minute or 5 minute interval (or alternatively time duration could be specified in multiples of check frequency. Which then can be used dynamically for any duration the check has. E.g. 2 times the frequency of the check or 3 times of the frequency of the check or 4 times the frequency of the check") .In other words time duration can be = 3 times. For a check of every minute it will be 1x3 or can just be 3 minute time duration. I like the time duration to be specified as number of checks. </li>
<li>Optional: Show to user number of checks that would be ran in the above selected duration.</li>
<li>Mandatory: Ask user the minimum amount of checks (checks number) failed in the above duration for which the alert shall be risen. </li>
</ul>
Then during check lifetime if during the specified time duration the number of failed checks is &gt;= checks numbers the alert is raised. 
During next time duration If there is already an open alert and again number of failed checks is &gt;= checks numbers then alert is kept open otherwise it is closed. 
Such way of alert generation could allow flapping detection and would also alert on total downtime. 
For example for me: 
We have 13 nodes behind a web site and sometimes randomly 1 of those would fail and keep failing. 
Normal logic - checkly would raise 1 alert and close it once it hits randomly this one node. 
With above logic I could setup following - if during 10 checks(10 minutes) I have one or more failure I would like to alert, 
which would stay open while we continuosly have this or more number of alerts in those 10 minute intervals. 
Describe alternatives you've considered
There is no other way to implement this with current logic
However, since I am sure the above algorithm is not the only one for flapping detection any other AI or smart or self-adjusting mechanims is good as well. 
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/186">https://github.com/checkly/public-roadmap/issues/186</a>

Flapping detection

<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

Describe the solution you'd like
Checkly's existing alert channels cover almost all the mediums from which I need alerts, except for something that will ring persistently and wake me from sleep — a phone call. :)
Describe alternatives you've considered
There are more comprehensive solutions that presumably include phone call alerts, as part of their broader suites of functionality -- PagerDuty, OpsGenie, Spike, etc. I'm working on cobbling this together via Checkly webhooks and the Twilio API -- https://www.twilio.com/docs/studio/rest-api/v2/execution -- but it'd be nice if this were as simple as configuring your other channels. 
Additional context
I'm not looking for comprehensive stuff like scheduling, multiple phone number support, etc. Just a simple phone call to a single number if there's an outage.
Thanks for considering!
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/199">https://github.com/checkly/public-roadmap/issues/199</a>

Alert channel for Phone calls

<h1 id="problem">Problem</h1>
It's now not possible to attribute who created a check, snippet or any other entity in Checkly and who edited it afterwards. 
<h1 id="solution">Solution</h1>
<ul>
<li>track creator and editors for all entities in Checkly</li>
<li>show user avatars on the UI (similar to GitHub or any other SaaS product showing creators and editors)
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/202">https://github.com/checkly/public-roadmap/issues/202</a></li>
</ul>

User activity metadata in UI and DB

💡 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

Is your feature request related to a problem? Please describe.
We grouped our checks in Checkly on a per-customer basis, however not all checks for each customer can be done from the same location. For example, some internal applications can only be tested from private locations and vice versa for public endpoints. Currently it's not possible to override the location for a single check.
Describe the solution you'd like
The ability to override the locations per check in a group.
Describe alternatives you've considered
Ability to create subgroups with separate location settings, so you can divide external and internal checks.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/223">https://github.com/checkly/public-roadmap/issues/223</a>

Override locations in grouped 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.
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 now apparently have two Checkly accounts: one for when I sign in with Google and the other when I sign in with GitHub. Even though both are using the same e-mail address. This is confusing and not how I see OAuth 2.0 implemented by other web apps. 
I would like Checkly to determine the account based solely on the e-mail address and not based on the combination of e-mail address and OAuth 2.0 provider. Existing "duplicate" accounts should ideally be merged somehow.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/231">https://github.com/checkly/public-roadmap/issues/231</a>

Link account to e-mail address

Spoke to support, very helpful. Suggested I create an enhancement for review:
Our use case: allow the team to quickly understand the motivation behind created checks without going into each one.
Internal only (not public).
An example implementation that would work for us: 
<ol>
<li>An additional optional field in the check setup that allows input of freeform text description</li>
<li>When a description is present, show a small informational icon/symbol e.g.
<img src="https://user-images.githubusercontent.com/1254905/185588296-3d368eef-cae1-4ebe-9f37-83ec6d6321e2.png" alt="image" />
on the check in the home screen (similar to how tags show up)</li>
<li>When mouse hovering the info icon on the home screen check, the description snippet is displayed as a hovering tooltip so the user can quickly scan checks and pull up more detail if required
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/241">https://github.com/checkly/public-roadmap/issues/241</a></li>
</ol>

Enhancement: Check Descriptions

Is your feature request related to a problem? Please describe.
When the checkly alert comes to us via opsgenie, there's a lot of clicking to get through the dashboard and edit the alert to see what conditions led to a failure and then go checking internal playbooks for what went wrong.
Describe the solution you'd like
Per-alert "descriptions", as a freeform text field, which can be populated with whatever we think fit, and which are passed to the API of the alerting systems. Eg, in OpsGenie the new alert API has a "description" field with a 15,000 character limit. We'd like to be able to populate that with something other than <code>View your failing check in the Checkly dashboard</code>.
We'd then populate it with a concise human summary of what the alert is checking for, and a link to playbook documentation, to speed the time to comprehension when someone is woken up at 3am.
We might want multiple paragraphs for some situations, to have initial process checks be in the description. But we could live with a single paragraph if absolutely necessary. I've seen multiple paragraphs work very well in other monitoring systems.
Describe alternatives you've considered
Decorating elsewhere, which requires multiple sources of truth and a lot of complexity.
Additional context
Two existing issues relate to having descriptions, but not to the aspect of being able to pass that through to the alerting system and are more concerned with dashboard clutter. Those sound like short descriptions, not multiple paragraphs, else they'd just be a tab. So not the same. Those issues are: #241 and #133 
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/256">https://github.com/checkly/public-roadmap/issues/256</a>

Per-alert descriptions fed to alerting integrations

💡 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.
A clear and concise description of what the problem is. Ex. 
We have good amount of requests originating towards our websocket API's and for that we require support via checkly. 
Describe the solution you'd like
A clear and concise description of what you want to happen.
We wish to have websocket check support via checkly as soon as possible. 
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
<ul>
<li>currently we tend to use local solution but we will look other options if required, since this is a very important usecase for our engineering teams. </li>
</ul>
Additional context
Add any other context or screenshots about the feature request here.
Here is the curl request i am trying to import in checkly but it does nothing: 
<pre><code>curl --include \
--no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Host: echo.websocket.org" \
--header "Origin: http://echo.websocket.org" \
--header "Sec-WebSocket-Version: 13" \
http://echo.websocket.org
</code></pre>
I would assume since websocket is a layer above http, it should be possible to have a HTTP client capable to support this within checkly. 
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/273">https://github.com/checkly/public-roadmap/issues/273</a>

Websocket API check support

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>

Manually edit incident timestamps

Is your feature request related to a problem? Please describe.
We are running the same checks against different, duplicate environments. With the current UI where we can only have groups, and only one level of groups, it can become harder to reason around the checks.
Describe the solution you'd like
Having workspaces/projects per environment would let us group checks in a logical way. It could also give a realistic overview of the passed/degraded/failing checks, as that could be per workspace/project. It would also enable things like having code snippets/alert rules etc specific to a workspace/project.
Describe alternatives you've considered
Having multiple levels of grouping could somewhat alleviate the issue, but the overview of passed/degraded/failing checks would not be as useful, as it would not be possible to know if the issue is in multiple environments or isolated to one environment.
We could also set up multiple organisations, but that is something we want to avoid. Logically it isn't separate organisations, and we want to have the same payment/contact/users/access control etc.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/279">https://github.com/checkly/public-roadmap/issues/279</a>

Support for grouping into workspaces/projects

Is your feature request related to a problem? Please describe.
I'm creating browser checks for web3 application. This app uses web3 provider (wallet), that is usually provided by browser extension (e.g. Metamask), but for Playwright tests it's possible to use headless provider (headless-web3-provider npm dep). The implementation relies on <code>ethers.js</code> npm package.
So I'm including all those npm deps by bundling them into the js script. Unfortunately <code>ethers.js</code> lib is big (&gt; <code>300Kb</code>), and I have been told that the Checkly script size limit is only 256Kb
Describe the solution you'd like
Ideally to have a <code>ethers</code> (and posibly <code>rxjs</code>) in the default runtime.
Describe alternatives you've considered
Increase the script size limit to 1Mb (500Kb works too)
or to have ability to install npm dependencies defined in package.json (or any other way)
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/281">https://github.com/checkly/public-roadmap/issues/281</a>

Include ethers.js in runtime

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 href="https://github.com/checkly/public-roadmap/issues/282">https://github.com/checkly/public-roadmap/issues/282</a>

Support for toHaveScreenshot using artifact management / Add a visual comparison NPM package to runtimes

Is your feature request related to a problem? Please describe.
Checkly agent is great but it is a lot of manual work to get it up and running in my Kubernetes cluster. I need to understand the <a href="https://www.checklyhq.com/docs/private-locations/checkly-agent-guide/">documentation</a> and then translate this into a Deployment spec and run it in my cluster.
Describe the solution you'd like
I'd like to have a Helm chart, where a new installation would be only three steps:
<pre><code>helm repo add checkly https://charts.checklyhq.com
helm repo update
helm upgrade --install checkly-agent checkly/checkly-agent \
 --set config.api_key='YOUR.AGENT.API.KEY'
</code></pre>
or to update to a new version
<pre><code>helm repo update
helm upgrade checkly-agent checkly/checkly-agent --reuse-values
</code></pre>
All customizations would happen in a Helm style in a separate <code>values.yaml</code>.
Describe alternatives you've considered
Hand roll it by myself in my cluster. Write my own Helm chart. Use other config management tools like Terraform or Ansible to write the deployment.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/285">https://github.com/checkly/public-roadmap/issues/285</a>

Provide a Helm chart for Checkly Agent

Browser report page should include timelines and page navigations for all tabs/pages opened in a test. Many web applications open links in new tabs/pages with normal usage and this should be included in report.
Reproduction steps:
<pre><code class="Typescript language-Typescript">import { test, expect } from '@playwright/test'

test('Simple multipage', async ({ page }) =&gt; {
 await page.goto('https://www.checklyhq.com/')
 const page1Promise = page.waitForEvent('popup')
 await page.locator('#nav-signup-button').click()
 const page1 = await page1Promise
 await expect(page1.getByRole('button', { name: 'Sign Up' })).toBeVisible()
})
</code></pre>
As seen on attached snapshot only first tab is tracked and timelines and page navigations for signup page aren't.
<img src="https://user-images.githubusercontent.com/14159649/220392762-9c6c8f35-3a78-4fbc-ac0e-cbff5db38bcb.png" alt="image" />
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/287">https://github.com/checkly/public-roadmap/issues/287</a>

Test results should support multipage

💡 Join our <a href="https://www.checklyhq.com/slack">Slack Community</a> to ask general questions, suggest ideas and get direct help from all the folks at Checkly.
Is your feature request related to a problem? Please describe.
 I was checking if I can see uptime numbers averaged and shown on the Group directly. It would help me understand uptime numbers on the Group which is tenant for us
Describe the solution you'd like
Adding group based uptime numbers
Describe alternatives you've considered
Additional context
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/289">https://github.com/checkly/public-roadmap/issues/289</a>

Uptime numbers at Group level

We regularly release new Runtimes with updated NPM packages. We would love to hear which 3rd party NPM packages you rely on and are missing in our Runtime.
<ul>
<li><a href="https://www.checklyhq.com/docs/runtimes/">How Runtimes work</a></li>
<li><a href="https://www.checklyhq.com/docs/runtimes/specs/#npm-packages">Current Runtimes and included packages</a></li>
</ul>
Please comment below with a package name you would love to see in our next Runtime!
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/291">https://github.com/checkly/public-roadmap/issues/291</a>

Suggest NPM packages to include in the Checkly Runtime

💡 Join our <a href="https://www.checklyhq.com/slack">Slack Community</a> to ask general questions, suggest ideas and get direct help from all the folks at Checkly.
Is your feature request related to a problem? Please describe.
We have hundreds of checks on checkly and its difficult to navigate to all pages to check the status for each check.
Describe the solution you'd like
Adding a search functionality on statuspage to filter only required checks
Describe alternatives you've considered
None
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/292">https://github.com/checkly/public-roadmap/issues/292</a>

Search bar on the status page

We receive frequent alerts due to alleged service degradation which can't be reproduced on our end. Our servers run in Germany (Hetzner, Falkenstein), and we perform checks using Frankfurt and other European regions. Sometimes we do receive degradation alerts from Ireland/Milan since the HTTP request took more than 3 seconds. These are always one-time incidents, the next check works fine, and we don't see slow response times in our access logs and almost never receive degradation alerts from Frankfurt.
It would be great if there could be additional thresholds for degradation alerts, e.g. only alert after three successive degradations were observed, or only if the degradation is observed from all regions simultaneously. 
For now we're limiting the checks to only Frankfurt and Paris and enable double checks in order to hopefully reduce the amount of incorrect alerts we receive. Please let me know if you need more information.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/293">https://github.com/checkly/public-roadmap/issues/293</a>

More control over service degradations

We have been using Checkly for 2 years now to monitor our infrastructure. One thing that we really want that we want to be able to send screenshots of failed tests to Slack. Currently, it just notifies via Slack that a test fails. We won't know details until we log into the Checkly. If Checkly can attach a screenshot of the failed test to Slack would be great. So, we know immediately what happened. Especially when you use mobile devices.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/294">https://github.com/checkly/public-roadmap/issues/294</a>

Ability to attach screenshot to Slack alert

💡 Join our <a href="https://www.checklyhq.com/slack">Slack Community</a> to ask general questions, suggest ideas and get direct help from all the folks at Checkly.
Is your feature request related to a problem? Please describe.
Some services are impacted by intermittent/transient disruptions which last longer than the inbuilt retry policy, but are often resolved before notifications reach our team.
We would like a way to distinguish an ongoing outage, vs a transient error.
The current auto-retry policy makes a second attempt too soon after the first attempt, and is often impacted by the same transient error.
This feature would potentially also allow more accurate tracking of time-based metrics, as check frequency could be increased during outages to get more accurate duration information.
Describe the solution you'd like
I'd like to be able to have 2 distinct check rates - one for when everything is working as expected, and a separate one for when the check is in a fail state.
Describe alternatives you've considered
<ul>
<li>We've considered using the API to manually adjust the check frequency during an outage; this seems heavy handed at this stage.</li>
<li>We've considered writing retry logic into our tests; This would throw out performance metrics as tests could take wildly different amount of time.</li>
<li>One alternative would be a way to adjust the amount of time before the automatic retry occurs; This would be the MVP for this feature, but it would be far more powerful as a distinct rate for any check in a fail state.</li>
<li>Another alternative would be a way to adjust the number of failures that must occur before a check is considered failed; This is already partially implemented by the "Double check on failure" feature, but there's no way to configure this to wait X seconds before performing the second check.</li>
</ul>
Additional context
<ul>
<li>Ideally, any change in frequency should impact metrics (availability/p95/etc) in a time-based fashion, not a count-based fashion.</li>
<li>This feature request also opens the pathway to "retry policies", which would allow the user to either choose from a defined set of policies (exponential / linear / constant) or set their own policies, which would allow you to adjust the duration between consecutive retry attempts. This could even go so far as to allow the user to specify how many checks must fail before a test is marked "failed" vs "degraded"
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/298">https://github.com/checkly/public-roadmap/issues/298</a></li>
</ul>

Adjustable check frequency upon failed requests

💡 Join our <a href="https://www.checklyhq.com/slack">Slack Community</a> to ask general questions, suggest ideas and get direct help from all the folks at Checkly.
Is your feature request related to a problem? Please describe.
A domain was resolving to a cloud provider's service through 2 IPs, one of these IPs was not responding causing the checks to fail but the other IP did respond so overall we were seeing intermittent check failures but the service was healthy and up all the time.
Describe the solution you'd like
If the api check can log which IP it was calling when the domain was resolved, it would help us quickly identify that there is a bad IP 
Describe alternatives you've considered
We did the DNS lookups to find the IPs and made requests ourselves to see this behaviour but that was only when we realised that this might be the cause
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/299">https://github.com/checkly/public-roadmap/issues/299</a>

Log the IP address of the endpoint that is being called by an API healthcheck

💡 Join our <a href="https://www.checklyhq.com/slack">Slack Community</a> to ask general questions, suggest ideas and get direct help from all the folks at Checkly.
Is your feature request related to a problem? Please describe.
You recently added incident management for dashboards. This feature got us thinking if we could ditch our (overpriced) <a href="https://status.afosto.app">statuspage</a>. This page currently shows metrics (we ingest manually) for example for our General API performance. We would love to keep this metric on our statuspage but not bother our customers with all the specific checks we are running on our API's (they are way to detailed / technical)
Describe the solution you'd like
I can see us use the statuspage feature (with incident management) and replace our current statuspage. The thing is, we would love to maintain a sort of performance chart of the overall API score / performance. Some sort of average metric over (a group of tagged) currently active checks.
Since Checkly is already running checks and collects relevant metrics regarding our API response time / uptime we would also no longer be required to manually ingest API metrics into our Atlassian Statuspage. 
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
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/301">https://github.com/checkly/public-roadmap/issues/301</a>

Grouped check metrics on dashboard to replace our current statuspage

Is your feature request related to a problem? Please describe.
Currently, there's no way to disable performance metrics from being displayed on public dashboards (status page).
Describe the solution you'd like
Include a checkbox on the dashboard's edit page to disable displaying performance metrics.
Describe alternatives you've considered
Considered using CSS to hide performance metrics, but this has a few problems:
<ol>
<li>It only hides them, but they're still available on the HTML;</li>
<li>It also hides the availability/uptime percentage, as it shares the CSS class with the P metrics;</li>
<li>The width of the graphs doesn't increase/adjust, so we end up with a white space where metrics were being displayed;</li>
<li>Should the CSS class change, the work around will not work anymore.</li>
</ol>
Additional context
Without that toggle we won't be able to use the public dashboard and will need to consider other solution for this, which decreases the value we get from using Checkly.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/303">https://github.com/checkly/public-roadmap/issues/303</a>

Allow perf metrics to be disabled on dashboard/status page

Is your feature request related to a problem? Please describe.
 The <code>checkly_check_status</code> metric provides the status of the core check, i.e the check either passes or fails. We have no metric that tells us if the SSL certificate expiration check has failed, i.e a certificate is going to expire in X number of days.
It would be great if information was exposed as a metric. This would allow the creation of create custom alerts and dashboards etc. to display a list of certificates and if possible, also their expiry date.
Describe the solution you'd like
Metrics that tell me if an SSL certificate check failed and also the certificates expiry date.
Additional context
Original request: https://checklycommunity.slack.com/archives/C04349E26EN/p1683124146213909
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/305">https://github.com/checkly/public-roadmap/issues/305</a>

SSL certificate expiration metric

💡 Join our <a href="https://www.checklyhq.com/slack">Slack Community</a> to ask general questions, suggest ideas and get direct help from all the folks at Checkly.
Is your feature request related to a problem? Please describe.
I would like the ability to control the timeline of my checks (beyond the last 48). Such that if I want 48 checks/hour I can still have the last 24 hours, just checkly will store that data longer and then my status page if I set to last 24 hours (or longer or shorter) it'll be available to me.
Describe the solution you'd like
I want to be able to control the timeline of the checks that I have on my status page. 
As you can see this shows only the last hour and I would like to increase that time range (to lets say last 48hours).
<img width="1057" alt="Screen Shot 2023-05-08 at 10 50 43 AM" src="https://user-images.githubusercontent.com/30190842/236856521-a9d17397-e38d-42e2-b676-905992693900.png">
Describe alternatives you've considered
N/A
Additional context
Screenshot above.
original GH issue link <a href="https://github.com/checkly/public-roadmap/issues/308">https://github.com/checkly/public-roadmap/issues/308</a>