v2.0.0

Version 2 of the Checkly provider is built on the Terraform Plugin Framework instead of the Terraform Plugin SDK v2. It is a major release: configurations need changes, and some values change on the first apply. Existing state is upgraded automatically, so no resource has to be imported or recreated.

Before upgrading, read the upgrade guide. It has a step-by-step procedure, every configuration change with before-and-after examples, and the full list of one-time changes the first plan can show. The CHANGELOG lists every change.

Requirements

• Terraform 1.8 or later. The provider serves plugin protocol 6 only. Upgrade Terraform first, while still on v1.x.
• An account ID for every API key, as a UUID, through account_id or CHECKLY_ACCOUNT_ID.

Breaking changes

Configuration syntax

• No resource has blocks any more. Single nested objects are attributes: alert_settings = { ... } instead of alert_settings { ... }.
• Repeatable blocks are list or set attributes with plural names, so they can be assigned from expressions instead of dynamic blocks. For example, alert_channel_subscriptions = [{ ... }] replaces alert_channel_subscription { ... }. The same goes for environment_variable, component, card, assertion and device.
• environment_variables as a map is removed on checkly_check and checkly_check_group. Write each entry as an element of the environment_variables list.
• No group or snippet is null, not 0. group_id, setup_snippet_id and teardown_snippet_id must be at least 1. Replace var.grouped ? checkly_check_group.example.id : 0 with null.

terraform validate points at every line that needs to change, except misspelled names inside objects written as { ... }, which Terraform ignores.

Removed

• checkly_trigger_check and checkly_trigger_group. Take them out of your configuration and state before upgrading. Use checkly trigger or POST /v1/check-sessions/trigger instead.
• Attributes the API ignored: ssl_check on checkly_check, alert_settings.ssl_certificates, retry_strategy.only_on on monitors without conditions, and should_fail everywhere except API checks, URL monitors and TCP monitors.
• The CHECKLY_DEBUG_LOG request dump. Use an HTTPS proxy through HTTPS_PROXY to inspect requests.

Behaviour

• Credentials are sensitive, including nested ones. An output that exposes one, such as a heartbeat ping URL built from ping_token, must set sensitive = true.
• Values that v1.x could not clear are cleared. A value set in the web app and absent from your configuration is erased by the first apply. This covers, for example, tags and group_order on checks and monitors, and logo, favicon and custom_domain on status pages and dashboards. The upgrade guide lists every one; add a value to your configuration to keep it.
• Unset optional attributes without a default are stored as null, not "" or 0. A configuration that sets one of them to "" or 0 explicitly plans one in-place update.
• use_global_alert_settings is derived from alert_settings when it isn't set, as in the Checkly CLI. It is true when alert_settings isn't set either, and false when it is. Most resources defaulted it to false before, so the first plan can switch their alerts to the account level alert settings. Set use_global_alert_settings = false to keep the old behaviour.
• Much more is validated at plan time. Values the API rejects, silently changes or never applies now fail the plan instead of failing at apply or showing a change on every plan. This covers lengths and formats, enums, port ranges, monitor modes and assertions, ICMP packet loss thresholds of 0, maintenance window dates and secret environment variable values shorter than 3 characters. Some configurations that applied with v1.x now fail the plan; each attribute's documentation states its restrictions.
• checkly_check writes through the API endpoint of each check type. Attributes that don't apply to the type have no effect and give a warning. Every update of a browser or multi-step checkly_check clears the script path and dependencies that the Checkly CLI sets; move the check to checkly_browser_check or checkly_multistep_check to keep them.
• Changing slug_name of a checkly_private_location fails the plan. The API never changes a slug.

Changed defaults

Monitors that leave these out plan an update to the new values on the first apply. Set them explicitly to keep the old limits.

Resource	Attribute	v1.x	v2
checkly_ssl_monitor	degraded_response_time / max_response_time	10000 / 20000	3000 / 10000
checkly_tcp_monitor, checkly_tcp_check	degraded_response_time	4000	3000
checkly_traceroute_monitor	degraded_response_time / max_response_time	10000 / 20000	500 / 1000
checkly_dashboard	sort_by_status / show_group_names	reset on every update	false / true
checkly_alert_channel	auto_subscribe	turned off on every update	false

max_response_time = 0 on checkly_traceroute_monitor is now sent, and means the monitor never fails on response time.

The new checkly_api_check follows redirects by default (request.follow_redirects = true) and defaults to degraded_response_time = 5000 and max_response_time = 20000, as the web app and the Checkly CLI do. checkly_check keeps false, 15000 and 30000; set them explicitly when you move a check to checkly_api_check to keep the previous behaviour.

New resources

• checkly_api_check, checkly_browser_check and checkly_multistep_check replace checkly_check. Each one exposes only the attributes of its check type. checkly_browser_check and checkly_multistep_check add script_path and dependencies for multi-file scripts.
• checkly_maintenance_window replaces checkly_maintenance_windows and manages a single window.

A moved block switches a resource to its replacement without recreating it, in the same plan as the provider upgrade.

New attributes

• intent and ai_auto_repair_enabled on checks and checkly_playwright_check_suite.
• private_locations on checkly_dns_monitor, checkly_icmp_monitor and checkly_traceroute_monitor, and proxy_url on checkly_private_location.
• component_configs on maintenance windows' status_page_visibility, to show a window on v3 status pages with the affected components.
• sort_by_status and show_group_names on checkly_dashboard.
• auto_subscribe on checkly_alert_channel.
• ip_family = "all" on the checkly_static_ips data source, now the default.
• record_type = "HTTPS" and every assertion comparison the API accepts on checkly_dns_monitor, and the remaining JSON_RESPONSE comparisons on checkly_icmp_monitor.
• Slack channel IDs, such as C0123456789, in slack_app.slack_channels of checkly_alert_channel. An ID keeps working when the channel is renamed, and is the way to address a private channel.
• degraded_response_time and max_response_time accept up to 45000 on TCP and URL monitors and API checks if extended limits have been approved for your account. On other accounts, a value above the standard limit (5000 for TCP, 30000 for URL monitors and API checks) fails the plan.
• activated and frequency are optional on every check, monitor and checkly_check_group, with the API defaults true and 10.
• Import instructions on every importable resource's documentation page.

Deprecated

These keep working in v2, and moved blocks switch them to their replacements:

• checkly_check → checkly_api_check, checkly_browser_check and checkly_multistep_check
• checkly_check_group → checkly_check_group_v2
• checkly_heartbeat → checkly_heartbeat_monitor
• checkly_tcp_check → checkly_tcp_monitor
• checkly_maintenance_windows → checkly_maintenance_window
• checkly_status_page and checkly_status_page_service → the v3 status page resources
• slack on checkly_alert_channel → slack_app

Notable fixes

• Only real 404 responses remove a resource from state.
• Many attributes that showed the same change on every plan no longer do, such as a dashboard's key, maintenance window dates written in another form than the API's, and removed tags or group_order.
• Updating a checkly_url_monitor keeps request headers set in the web app.
• Importing a checkly_client_certificate no longer replaces it on the first apply.
• Requests that get no response are re-sent when that can't apply a change twice, and rate-limited requests are retried.
• API errors name the request, the status and the API's message.

Known issue

A description that contains &, <, > or HTML is stored HTML-encoded by the Checkly API, for example & as &. Until a fix in the API is deployed, Terraform sees the stored value differ from the configuration: the apply can fail with an inconsistent result error, or every plan shows a change to description. Avoid these characters in descriptions for now, or add description to lifecycle { ignore_changes = [...] }. No provider upgrade is needed once the API is fixed.

Full Changelog: v1.32.0...v2.0.0