Make AI context explicit and close the loop from generated check to validated fix
I recently used Checkly’s AI Assistant to create a monitoring plan for WERESK, my production SaaS platform. The first-run experience was impressive: after exploring three public endpoints, Checkly generated and deployed eleven URL, API, browser, DNS and heartbeat checks within minutes. However, creating the checks happened much faster than understanding how they worked, how reliable they were and which AI surface I should use when something failed. The problem One generated browser check for the anonymous demo flow failed immediately. The application itself loaded correctly, but the generated test expected profile or card elements to be visible on the first page: [data-testid="profile-card"], [data-testid="profile-row"], table tbody tr, [class*="profile"], [class*="card"] In the actual application, /demo initially displays a static dashboard. The user must first click “Profiles” before the profiles table and search field become visible. The generated check therefore represented an incorrect user flow and used broad CSS selectors that did not correspond to the actual DOM structure. Rocky AI correctly recognized that the selector might be wrong and allowed me to add application context. However, the next action was not obvious. There was no direct way to ask AI to update the generated check, review a proposed change, rerun it and save the working version. At the same time, Checkly presents several AI entry points: the global AI Assistant used to explore a platform and create monitoring plans; Rocky AI and its Context field used to analyse failed checks; “Ask AI” inside the support widget, apparently intended for product help and documentation. For a new user, it is not immediately clear: what context each AI assistant can access; whether it understands the monitored application, the Checkly account, the current check or only Checkly documentation; whether it can analyse, explain, modify or deploy resources; where a user should continue after an AI-generated check fails; whether context added to Rocky AI is available when editing or regenerating the check. There is also no contextual tutorial explaining these boundaries during the first real monitoring workflow. Suggested solution I would make the scope and capabilities of every AI surface explicit and connect them into a single recovery workflow. For example, each AI interface could state its current context: “Working with your Checkly account and monitoring plan” “Analysing this check and its latest failed run” “Answering questions about Checkly” “Using the application context you provided” For AI-generated checks, the failed-run experience could offer a guided loop: Detect whether the failure most likely comes from the monitored application, test design, locator or environment. Show the evidence used for that classification. Let the user add missing application context. Generate a proposed patch to the check. Present the code diff and explain what will change. Run the updated check without immediately replacing the active version. Compare the new result with the failed run. Save the change only after successful validation. In my case, this workflow could have identified that the page loaded correctly, discovered the visible “Profiles” navigation control, proposed clicking i
Alexey Musatov 4 days ago
Make AI context explicit and close the loop from generated check to validated fix
I recently used Checkly’s AI Assistant to create a monitoring plan for WERESK, my production SaaS platform. The first-run experience was impressive: after exploring three public endpoints, Checkly generated and deployed eleven URL, API, browser, DNS and heartbeat checks within minutes. However, creating the checks happened much faster than understanding how they worked, how reliable they were and which AI surface I should use when something failed. The problem One generated browser check for the anonymous demo flow failed immediately. The application itself loaded correctly, but the generated test expected profile or card elements to be visible on the first page: [data-testid="profile-card"], [data-testid="profile-row"], table tbody tr, [class*="profile"], [class*="card"] In the actual application, /demo initially displays a static dashboard. The user must first click “Profiles” before the profiles table and search field become visible. The generated check therefore represented an incorrect user flow and used broad CSS selectors that did not correspond to the actual DOM structure. Rocky AI correctly recognized that the selector might be wrong and allowed me to add application context. However, the next action was not obvious. There was no direct way to ask AI to update the generated check, review a proposed change, rerun it and save the working version. At the same time, Checkly presents several AI entry points: the global AI Assistant used to explore a platform and create monitoring plans; Rocky AI and its Context field used to analyse failed checks; “Ask AI” inside the support widget, apparently intended for product help and documentation. For a new user, it is not immediately clear: what context each AI assistant can access; whether it understands the monitored application, the Checkly account, the current check or only Checkly documentation; whether it can analyse, explain, modify or deploy resources; where a user should continue after an AI-generated check fails; whether context added to Rocky AI is available when editing or regenerating the check. There is also no contextual tutorial explaining these boundaries during the first real monitoring workflow. Suggested solution I would make the scope and capabilities of every AI surface explicit and connect them into a single recovery workflow. For example, each AI interface could state its current context: “Working with your Checkly account and monitoring plan” “Analysing this check and its latest failed run” “Answering questions about Checkly” “Using the application context you provided” For AI-generated checks, the failed-run experience could offer a guided loop: Detect whether the failure most likely comes from the monitored application, test design, locator or environment. Show the evidence used for that classification. Let the user add missing application context. Generate a proposed patch to the check. Present the code diff and explain what will change. Run the updated check without immediately replacing the active version. Compare the new result with the failed run. Save the change only after successful validation. In my case, this workflow could have identified that the page loaded correctly, discovered the visible “Profiles” navigation control, proposed clicking i
Alexey Musatov 4 days ago
Option to prevent overlapping runs for a check
Sometimes a check will run concurrently, like if the check has a scheduled run that overlaps with CI/CD- or locally-triggered runs. This is an issue for certain checks, especially login flows where the server only allows one login session per account. When the same check runs concurrently, they interfere with each other (like the first check logging out of the session, causing the second check to fail). It would help to have a per-check toggle (max concurrency = 1) that waits for existing runs to finish if the same check is already in-flight, regardless of trigger source.
Laura Guo 21 days ago
Option to prevent overlapping runs for a check
Sometimes a check will run concurrently, like if the check has a scheduled run that overlaps with CI/CD- or locally-triggered runs. This is an issue for certain checks, especially login flows where the server only allows one login session per account. When the same check runs concurrently, they interfere with each other (like the first check logging out of the session, causing the second check to fail). It would help to have a per-check toggle (max concurrency = 1) that waits for existing runs to finish if the same check is already in-flight, regardless of trigger source.
Laura Guo 21 days ago
Members listing via the CLI and API: add sort options, filter by MFA and SSO status
Currently, checkly members displays MFA and SSO status as columns in the output, but there's no way to filter them from the CLI or API. Additionally, there are no built-in ‘sort’ options for any of the columns. It would be helpful to have: Filters for MFA and SSO Ability to sort by relevant columns
Laura Guo 28 days ago
Members listing via the CLI and API: add sort options, filter by MFA and SSO status
Currently, checkly members displays MFA and SSO status as columns in the output, but there's no way to filter them from the CLI or API. Additionally, there are no built-in ‘sort’ options for any of the columns. It would be helpful to have: Filters for MFA and SSO Ability to sort by relevant columns
Laura Guo 28 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 about 2 months ago
Check Types
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 about 2 months ago
Check Types
Nested groups (groups within groups)
Problem Users organize checks by feature using groups, but for large-scale accounts a single feature can contain hundreds of tests. Even after grouping by feature, the group itself becomes too large to navigate. There's currently no way to further subdivide a group into logical sub-groups while keeping them under one parent. Ask Support hierarchical groups: a group can contain other groups in addition to checks. Users should be able to nest groups multiple levels deep, move existing groups under a new parent, and view rollup status (pass/fail, availability, response time percentiles) at any level of the hierarchy. Example structures users want Payment (parent) > Credit card, ACH, Wallet (children) Authentication (parent) > Email auth, SSO, Social login (children) Account limits (parent) > v1, v2 (children)
Shawn Harris 20 days ago
Nested groups (groups within groups)
Problem Users organize checks by feature using groups, but for large-scale accounts a single feature can contain hundreds of tests. Even after grouping by feature, the group itself becomes too large to navigate. There's currently no way to further subdivide a group into logical sub-groups while keeping them under one parent. Ask Support hierarchical groups: a group can contain other groups in addition to checks. Users should be able to nest groups multiple levels deep, move existing groups under a new parent, and view rollup status (pass/fail, availability, response time percentiles) at any level of the hierarchy. Example structures users want Payment (parent) > Credit card, ACH, Wallet (children) Authentication (parent) > Email auth, SSO, Social login (children) Account limits (parent) > v1, v2 (children)
Shawn Harris 20 days ago
Ad-hoc test session for UI-triggered check runs
Problem Teams deploying to production frequently want to run quick sanity checks post-deploy by using the "Schedule Now" button in the Checkly UI to trigger specific checks across different groups. Today, results scatter back to each check's own group, so finding what you just ran means opening every group individually and matching on run time. With hundreds of checks per feature, this is painful. Ask Let a user select N checks from anywhere in the UI, run them together as an ad-hoc session, and see the consolidated results in one place (mirroring the Test Sessions view produced by npx checkly test, but for UI-triggered runs). The session should persist so the user can return to it, see who ran it, duration, pass/fail per check, and drill in. Why not the CLI workaround Test sessions via the CLI work well for teams already set up locally, but not for engineers who don't have the Checkly project cloned. The ask is specifically for this experience inside the Checkly UI, not the terminal.
Shawn Harris 20 days ago
Ad-hoc test session for UI-triggered check runs
Problem Teams deploying to production frequently want to run quick sanity checks post-deploy by using the "Schedule Now" button in the Checkly UI to trigger specific checks across different groups. Today, results scatter back to each check's own group, so finding what you just ran means opening every group individually and matching on run time. With hundreds of checks per feature, this is painful. Ask Let a user select N checks from anywhere in the UI, run them together as an ad-hoc session, and see the consolidated results in one place (mirroring the Test Sessions view produced by npx checkly test, but for UI-triggered runs). The session should persist so the user can return to it, see who ran it, duration, pass/fail per check, and drill in. Why not the CLI workaround Test sessions via the CLI work well for teams already set up locally, but not for engineers who don't have the Checkly project cloned. The ask is specifically for this experience inside the Checkly UI, not the terminal.
Shawn Harris 20 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 1 month ago
Groups
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 1 month ago
Groups
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 about 1 month ago
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 about 1 month ago
Support custom BaseURL in Opsgenie integration for JSM Operations
The current Opsgenie integration only supports a region selector (US/EU). Replacing or extending this with a configurable baseURL enables support for both standard Opsgenie and Jira Service Management (JSM) Operations. Given that Opsgenie is approaching End of Life (EOL) and migrating toward JSM Operations, allowing a flexible baseURL ensures seamless support for both services
Mounir Mannai about 1 month ago
Support custom BaseURL in Opsgenie integration for JSM Operations
The current Opsgenie integration only supports a region selector (US/EU). Replacing or extending this with a configurable baseURL enables support for both standard Opsgenie and Jira Service Management (JSM) Operations. Given that Opsgenie is approaching End of Life (EOL) and migrating toward JSM Operations, allowing a flexible baseURL ensures seamless support for both services
Mounir Mannai about 1 month 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 1 month ago
CLI
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 1 month ago
CLI
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 1 month 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 1 month 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 1 month ago
Public API
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 1 month ago
Public API
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 1 month 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 1 month ago
Next
Option to sync between UI and CLI
If a change is made in the UI when CLI is source of truth, have to have to run npx checkly destroy --preserve-resources and reimport everything. Can you make a way to sync either way - from UI to CLI or CLI to UI?
hallt 2 months ago
CLI
Next
Option to sync between UI and CLI
If a change is made in the UI when CLI is source of truth, have to have to run npx checkly destroy --preserve-resources and reimport everything. Can you make a way to sync either way - from UI to CLI or CLI to UI?
hallt 2 months ago
CLI
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 about 2 months 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 about 2 months ago
Alternate middle east location while Bahrain is unoperational
Currently, our Bahrain region is out of commission due to war in that area. It would be helpful to have an alternative middle east location to monitor from.
Laura Guo 2 months ago
Alternate middle east location while Bahrain is unoperational
Currently, our Bahrain region is out of commission due to war in that area. It would be helpful to have an alternative middle east location to monitor from.
Laura Guo 2 months 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 about 2 months ago
Public API
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 about 2 months ago
Public API
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 2 months ago
Alerting
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 2 months ago
Alerting
npm runtime package request: @modelcontextprotocol/sdk
we want to check mcp server availability like connecting and list tools
Emil Ksenzovsky about 2 months ago
Runtimes
npm runtime package request: @modelcontextprotocol/sdk
we want to check mcp server availability like connecting and list tools
Emil Ksenzovsky about 2 months ago
Runtimes