---

generated by https://github.com/hashicorp/terraform-plugin-docs

page_title: "checkly_tcp_check Resource - terraform-provider-checkly" subcategory: "" description: |- The checkly_tcp_check resource has been renamed to checkly_tcp_monitor to better reflect its position in the Checkly product lineup. The old resource type will not be deprecated until the Checkly provider is updated to the Terraform Plugin Framework, which makes it possible to easily move resources between resource types. We recommend using the checkly_tcp_monitor resource type for any new resources.

checkly_tcp_check (Resource)

The checkly_tcp_check resource has been renamed to checkly_tcp_monitor to better reflect its position in the Checkly product lineup.

The old resource type will not be deprecated until the Checkly provider is updated to the Terraform Plugin Framework, which makes it possible to easily move resources between resource types.

We recommend using the checkly_tcp_monitor resource type for any new resources.

Example Usage

# Basic TCP Check
resource "checkly_tcp_check" "example-tcp-check" {
  name                      = "Example TCP check"
  activated                 = true
  should_fail               = false
  frequency                 = 1
  use_global_alert_settings = true

  locations = [
    "us-west-1"
  ]

  request {
    hostname = "api.checklyhq.com"
    port     = 80
  }
}

# A more complex example using assertions and setting alerts
resource "checkly_tcp_check" "example-tcp-check-2" {
  name                   = "Example TCP check 2"
  activated              = true
  should_fail            = true
  frequency              = 1
  degraded_response_time = 5000
  max_response_time      = 10000

  locations = [
    "us-west-1",
    "ap-northeast-1",
    "ap-south-1",
  ]

  alert_settings {
    escalation_type = "RUN_BASED"

    run_based_escalation {
      failed_run_threshold = 1
    }

    reminders {
      amount = 1
    }
  }

  retry_strategy {
    type                 = "FIXED"
    base_backoff_seconds = 60
    max_duration_seconds = 600
    max_retries          = 3
    same_region          = false
  }

  request {
    hostname = "api.checklyhq.com"
    port     = 80
    data     = "hello"

    assertion {
      source     = "RESPONSE_DATA"
      property   = ""
      comparison = "CONTAINS"
      target     = "welcome"
    }

    assertion {
      source     = "RESPONSE_TIME"
      property   = ""
      comparison = "LESS_THAN"
      target     = "2000"
    }
  }
}

<!-- schema generated by tfplugindocs -->

Schema

Required

• activated (Boolean) Determines if the check is running or not. Possible values true, and false.
• frequency (Number) Controls how often the monitor should run. Defined in minutes. The allowed values are 0 (high frequency - use frequency_offset to define the actual frequency), 1 (1 minute), 2 (2 minutes), 5 (5 minutes), 10 (10 minutes), 15 (15 minutes), 30 (30 minutes), 60 (1 hour), 120 (2 hours), 180 (3 hours), 360 (6 hours), 720 (12 hours) and 1440 (24 hours).
• name (String) The name of the check.
• request (Block Set, Min: 1, Max: 1) The parameters for the TCP connection. (see below for nested schema)

Optional

• alert_channel_subscription (Block Set) An array of channel IDs and whether they're activated or not. If you don't set at least one alert channel subscription for your monitor, we won't be able to alert you even if it starts failing. (see below for nested schema)
• alert_settings (Block List, Max: 1) Determines the alert escalation policy for the monitor. (see below for nested schema)
• degraded_response_time (Number) The response time in milliseconds starting from which a check should be considered degraded. Possible values are between 0 and 5000. (Default 4000).
• description (String) A description of the monitor.
• frequency_offset (Number) When frequency is 0 (high frequency), frequency_offset is required and it alone controls how often the monitor should run. Defined in seconds. The allowed values are 0 (disabled - use frequency to define the actual frequency), 10 (10 seconds), 20 (20 seconds) and 30 (30 seconds).
• group_id (Number) The id of the check group this check is part of.
• group_order (Number) The position of this check in a check group. It determines in what order checks are run when a group is triggered from the API or from CI/CD.
• locations (Set of String) An array of one or more data center locations where to run the this check. (Default ["us-east-1"])
• max_response_time (Number) The response time in milliseconds starting from which a check should be considered failing. Possible values are between 0 and 5000. (Default 5000).
• muted (Boolean) Determines if any notifications will be sent out when a check fails/degrades/recovers.
• private_locations (Set of String) An array of one or more private locations slugs.
• retry_strategy (Block List, Max: 1) A strategy for retrying failed check/monitor runs. (see below for nested schema)
• run_parallel (Boolean) Determines if the check should run in all selected locations in parallel or round-robin.
• runtime_id (String) The ID of the runtime to use for this check.
• should_fail (Boolean) Allows to invert the behaviour of when a check is considered to fail.
• tags (Set of String) A list of tags for organizing and filtering checks.
• trigger_incident (Block Set, Max: 1) Create and resolve an incident based on the alert configuration. Useful for status page automation. (see below for nested schema)
• use_global_alert_settings (Boolean) When true, the account level alert settings will be used, not the alert setting defined on this check.

Read-Only

• id (String) The ID of this resource.

<a id="nestedblock--request"></a>

Nested Schema for request

Required:

• hostname (String) The hostname or IP to connect to. Do not include a scheme or a port in this value.
• port (Number) The port number to connect to.

Optional:

• assertion (Block Set) A request can have multiple assertions. (see below for nested schema)
• data (String) The data to send to the target host.
• ip_family (String) The IP family to use when executing the TCP check. The value can be either IPv4 or IPv6.

<a id="nestedblock--request--assertion"></a>

Nested Schema for request.assertion

Required:

• comparison (String) The type of comparison to be executed between expected and actual value of the assertion. Possible values are EQUALS, NOT_EQUALS, HAS_KEY, NOT_HAS_KEY, HAS_VALUE, NOT_HAS_VALUE, IS_EMPTY, NOT_EMPTY, GREATER_THAN, LESS_THAN, CONTAINS, NOT_CONTAINS, IS_NULL, and NOT_NULL.
• source (String) The source of the asserted value. Possible values are RESPONSE_DATA and RESPONSE_TIME.

Optional:

• property (String)
• target (String)

<a id="nestedblock--alert_channel_subscription"></a>

Nested Schema for alert_channel_subscription

Required:

• activated (Boolean) Whether an alert should be sent to this channel.
• channel_id (Number) The ID of the alert channel.

<a id="nestedblock--alert_settings"></a>

Nested Schema for alert_settings

Optional:

• escalation_type (String) Determines the type of escalation to use. Possible values are RUN_BASED and TIME_BASED. (Default RUN_BASED).
• parallel_run_failure_threshold (Block List) Configuration for parallel run failure threshold. (see below for nested schema)
• reminders (Block List) Defines how often to send reminder notifications after initial alert. (see below for nested schema)
• run_based_escalation (Block List) Configuration for run-based escalation. (see below for nested schema)
• time_based_escalation (Block List) Configuration for time-based escalation. (see below for nested schema)

<a id="nestedblock--alert_settings--parallel_run_failure_threshold"></a>

Nested Schema for alert_settings.parallel_run_failure_threshold

Optional:

• enabled (Boolean) Whether parallel run failure threshold is enabled. Only applies if the monitor is scheduled for multiple locations in parallel. (Default false).
• percentage (Number) Percentage of runs that must fail to trigger alert. Possible values are 10, 20, 30, 40, 50, 60, 70, 80, 90, and 100. (Default 10).

<a id="nestedblock--alert_settings--reminders"></a>

Nested Schema for alert_settings.reminders

Optional:

• amount (Number) Number of reminder notifications to send. Possible values are 0, 1, 2, 3, 4, 5, and 100000 (0 to disable, 100000 for unlimited). (Default 0).
• interval (Number) Interval between reminder notifications in minutes. Possible values are 5, 10, 15, and 30. (Default 5).

<a id="nestedblock--alert_settings--run_based_escalation"></a>

Nested Schema for alert_settings.run_based_escalation

Optional:

• failed_run_threshold (Number) Send an alert notification after the given number of consecutive monitor runs have failed. Possible values are between 1 and 5. (Default 1).

<a id="nestedblock--alert_settings--time_based_escalation"></a>

Nested Schema for alert_settings.time_based_escalation

Optional:

• minutes_failing_threshold (Number) Send an alert notification after the monitor has been failing for the given amount of time (in minutes). Possible values are 5, 10, 15, and 30. (Default 5).

<a id="nestedblock--retry_strategy"></a>

Nested Schema for retry_strategy

Required:

• type (String) Determines which type of retry strategy to use. Possible values are FIXED, LINEAR, EXPONENTIAL, SINGLE_RETRY, and NO_RETRIES.

Optional:

• base_backoff_seconds (Number) The number of seconds to wait before the first retry attempt. (Default 60).
• max_duration_seconds (Number) The total amount of time to continue retrying the check/monitor (maximum 600 seconds). Available when type is FIXED, LINEAR, or EXPONENTIAL. (Default 600).
• max_retries (Number) The maximum number of times to retry the check/monitor. Value must be between 1 and 10. Available when type is FIXED, LINEAR, or EXPONENTIAL. (Default 2).
• only_on (Block List, Max: 1) Apply the retry strategy only if the defined conditions match. (see below for nested schema)
• same_region (Boolean) Whether retries should be run in the same region as the initial check/monitor run. (Default true).

<a id="nestedblock--retry_strategy--only_on"></a>

Nested Schema for retry_strategy.only_on

<a id="nestedblock--trigger_incident"></a>

Nested Schema for trigger_incident

Required:

• description (String) A detailed description of the incident.
• name (String) The name of the incident.
• notify_subscribers (Boolean) Whether to notify subscribers when the incident is triggered.
• service_id (String) The status page service that this incident will be associated with.
• severity (String) The severity level of the incident. Possible values are MINOR, MEDIUM, MAJOR, and CRITICAL.