Uptimeify Docs

Secrets and updates

How the Uptimeify provider keeps secrets out of state, how package limits show up in plan and apply, and how updates reach the API.

Secrets stay out of your state

Every secret is a write-only attribute ending in _wo: custom request headers, request bodies, authorization headers, basic auth passwords, webhook secrets and HMAC keys. OpenTofu and Terraform never store them in state, and the API never returns them.

Because the provider cannot read a write-only value back, it sends it only when the matching *_wo_version changes. To rotate a secret, change the value and increase the version:

resource "uptimeify_website" "api" {
  # ...
  custom_headers_wo = [
    { name = "X-Api-Key", value = var.api_key },
  ]
  custom_headers_wo_version = 2 # was 1: sends the new header
}

Attributes like has_custom_headers show whether a secret is set, without revealing it.

Package limits

Some checks depend on the customer's package, for example the keyword or page size check. If you switch on a check the package does not include, apply fails with checkNotInPackage instead of silently storing false. uptimeify_package_configs shows what each package allows.

A check without its companion value measures nothing. If you remove search_term, also remove or disable check_keyword_enabled. When the configuration leaves the switch out, the provider plans it off in the same update.

How updates reach the API

Most changes go out as a partial update that touches only the changed fields. A few fields (for website monitors: customer, check countries, HTTP method, redirects, cookies, auth and the write-only secrets) need the API's full update. The provider then sends every attribute, so nothing you did not change is reset. Details are on the resource page, for example uptimeify_website.

Drift

Changes made in the dashboard show up in the next plan and are reset on apply. Server-generated values (ids, heartbeat tokens, timestamps) are read-only and never cause drift.

On this page