betterstackhq / terraform-provider-better-uptime Goto Github PK

Hey 👋

Auth values are always showing up as changed...

# betteruptime_monitor.betteruptime_monitor_foo will be updated in-place
  ~ resource "betteruptime_monitor" "betteruptime_monitor_foo" {
      + auth_password         = (sensitive value)
      + auth_username         = (sensitive value)
        id                    = "1234"
        # (23 unchanged attributes hidden)
    }

My version:

$ terraform version
Terraform v1.1.9
on darwin_arm64
+ provider registry.terraform.io/betterstackhq/better-uptime v0.3.12

I try to set request headers, but it doesn't work.

resource "betteruptime_monitor" "api_graphql" {
  url              = "https://${var.ecs_subdomain_name}.${data.cloudflare_zone.default.name}"
  monitor_group_id = local.betteruptime.betteruptime_monitor_group_id
  monitor_type     = "status"
  http_method      = "POST"
  request_body     = jsonencode({query="query {authenticated}"})
  request_headers = [{Content-Type = "application/json"}]
}

Monitor is created, but no request header is defined.

suscribable is true by default on betteruptime_status_page resources, which is a paid feature, thus breaking resource creation for Free users:

Perhaps not setting a default value is a better choice.

Because the BetterUptime provider requires a separate API token per team, and we prefer to define all our BetterUptime resources in a single Terraform project, we need a unique API token per team in Terraform. This means multiple provider blocks are necessary (note that this is a little unusual... most providers allow a single global API token for the service/account) . However, if I configure the alias property, I get:

│ Error: Missing required argument
│ 
│ The argument "api_token" is required, but was not set.

If I remove the alias, which requires I only use a single BetterUptime provider block, this goes away. So, maybe it is a problem of not supporting the "alias", or maybe it is a problem validating the provider block?

This works:

provider "betteruptime" {
  api_token = data.sops_file.secrets.data["betteruptime_engineering_api_key"]
}

This does not work:

provider "betteruptime" {
  api_token = data.sops_file.secrets.data["betteruptime_engineering_api_key"]
  alias          = "engineering"
}

I'm running 0.3.20 of the provider and terraform 1.5.3.

The request_headers field has just been added to the API. It would be good if the betteruptime_monitor resource supported it.
See https://docs.betteruptime.com/api/monitors-api#creating-a-new-monitor

original issue: BetterStackHQ/deprecated-terraform-provider-betteruptime#4

The help text for betteruptime_monitor confirmation_period does not specify unit of time:

confirmation_period (Number) How long should we wait after observing a failure before we start a new incident?

In testing I found this to be seconds.

check_frequency has the following: In seconds.

Please append the help text for confirmation_period, team_wait, recovery_period to In seconds.

In the betteruptime_status_page_resource resource there is the ability to show history via the history boolean.

This is missing the ability, present in the GUI, to show the latency graph, which is very useful.

Under the USE PROVIDERS button in the Terraform Registry, the following code block appears:

terraform {
  required_providers {
    better-uptime = {
      source = "BetterStackHQ/better-uptime"
      version = "0.3.6"
    }
  }
}

provider "better-uptime" {
  # Configuration options
}

This hyphen breaks Terraform init because better-uptime is not a known provider:

│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/betteruptime: provider registry registry.terraform.io does not have a provider named
│ registry.terraform.io/hashicorp/betteruptime
│
│ All modules should specify their required_providers so that external consumers will get the correct providers when using a module. To see which modules are currently depending
│ on hashicorp/betteruptime, run the following command:
│     terraform providers

Status page API and corresponding web interface both support a history parameter used to set the number of days to display on the status page. Available values in the web interface are "90 days", "180 days" and "365 days"

betteruptime_status_page does not support such parameter. The following example with result in a Terraform unsupported argument error: An argument named "history" is not expected here.

resource "betteruptime_status_page" "this" {
  company_name             = "MyCompany"
  company_url              = "https://www.mycompany.com/"
  subdomain                = "status-mycompany"
  timezone                 = "Paris"
  history                  = 180
}

After removing the history parameter, the status pages created with the betteruptime_status_page Terraform will have a default 90 days status history.

When you have a betteruptime_monitor with verify_ssl = false and without setting the ssl_expiration variable, you get an error:

Error: PATCH https://betteruptime.com/api/v2/monitors/xxxxxxx returned 422: {"errors":{"base":["SSL expiration is invalid. Valid values are: [nil, 1, 2, 3, 7, 14, 30, 60]"]}}

Using verify_ssl = false should disable the need for the ssl_expiration variable. This can be done in more ways than one:

• Set a default value for ssl_expiration so you don't always have to set the variable
• Actually configure the API to not require a value for ssl_expiration

I successfuly created resources in Uptime but I am not able to do any updates.
Please tell me what am I missing here.

Required fields are filled out. It would help me to actually see what "unsupported values" and attributes are sent in the PATCH request to let me debug it.

Related: #75

Error

│ Error: PATCH https://betteruptime.com/api/v2/status-pages/184479 returned 422: {"errors":"Sorry, these attributes have unsupported values","allowed_values":{"layout":["vertical","horizontal"]}}
│
│   with module.uptime.betteruptime_status_page.this,
│   on ../modules/better-stack-uptime/main.tf line 7, in resource "betteruptime_status_page" "this":
│    7: resource "betteruptime_status_page" "this" {
│

Code

provider "betteruptime" {
  api_token = var.api_token
}

### status page ###

resource "betteruptime_status_page" "this" {
  company_name = "Company"
  company_url  = var.domain
  contact_url  = "mailto:[email protected]"
  timezone     = "Europe/Prague"
  subdomain    = "company-dev"
}

resource "betteruptime_status_page_section" "monitors" {
  status_page_id = betteruptime_status_page.this.id
  name           = "App"
  position       = 0
}

### monitors ###

resource "betteruptime_monitor" "app_onboarding" {
  url          = "${var.domain}/start"
  monitor_type = "status"
}

resource "betteruptime_monitor" "app_profile" {
  url          = "${var.domain}/landsman"
  monitor_type = "status"
}

resource "betteruptime_monitor" "app_profile_wall" {
  url          = "${var.domain}/landsman/wall"
  monitor_type = "status"
}

resource "betteruptime_monitor" "app_profile_stats" {
  url          = "${var.domain}/landsman/stats"
  monitor_type = "status"
}

resource "betteruptime_monitor" "app_profile_bio" {
  url          = "${var.domain}/landsman/bio"
  monitor_type = "status"
}

### link monitors to status page ###

resource "betteruptime_status_page_resource" "app_onboarding" {
  status_page_id = betteruptime_status_page.this.id
  resource_id    = betteruptime_monitor.app_onboarding.id
  resource_type  = "Monitor"
  public_name    = "onboarding"
}

resource "betteruptime_status_page_resource" "app_profile" {
  status_page_id = betteruptime_status_page.this.id
  resource_id    = betteruptime_monitor.app_profile.id
  resource_type  = "Monitor"
  public_name    = "profile index"
}

resource "betteruptime_status_page_resource" "app_profile_wall" {
  status_page_id = betteruptime_status_page.this.id
  resource_id    = betteruptime_monitor.app_profile_wall.id
  resource_type  = "Monitor"
  public_name    = "profile wall"
}

resource "betteruptime_status_page_resource" "app_profile_stats" {
  status_page_id = betteruptime_status_page.this.id
  resource_id    = betteruptime_monitor.app_profile_stats.id
  resource_type  = "Monitor"
  public_name    = "profile stats"
}

resource "betteruptime_status_page_resource" "app_profile_bio" {
  status_page_id = betteruptime_status_page.this.id
  resource_id    = betteruptime_monitor.app_profile_bio.id
  resource_type  = "Monitor"
  public_name    = "profile bio"
}

The UI for Status Pages allows enabling "Automatic reports", but the resource_status_page TF resource is missing the equivalent automatic_reports option.

Hello, this looks like a follow-up to #46 (ping @JanPokorny).

The following shows on terraform plan after a successful terraform apply:

  ~ resource "betteruptime_status_page" "example" {
        id                         = "123"
      + logo_url                   = "https://example.com/logo.png"
        # (18 unchanged attributes hidden)
    }

Moreover, I can see that if I apply again, the URL of the logo on the status page (hosted on uptime-storage.s3.amazonaws.com) changes.

Terraform v1.7.5
on linux_amd64
+ provider registry.terraform.io/betterstackhq/better-uptime v0.7.0

Example Terraform

resource "betteruptime_monitor" "betteruptime" {
monitor_type = "tcp"
port = "3128"
url = "test.example.com"
pronounceable_name = "The service name example"
recovery_period = "180"
check_frequency = "60"
regions = ["us", "eu", "au"]
ssl_expiration = "30"
domain_expiration = "30"
}

Error Message

Error: PATCH https://betteruptime.com/api/v2/monitors/835996 returned 422: {"errors": {"monitor_type":["is invalid. Valid values are: status, expected_status_code, keyword,keyword_absence"]}}

Expected Behaviour

Adds a monitor pointing to test.example.com:3128

I'm trying to update an existing email_integration. Specifically, I'm trying to add a the following fields;

cause_field {
    name  = "Caused by"
    content_after = "Description:"
    field_target  = "body"
    match_type    = "match_after"
  }

started_alert_id_field {
    name          = "Alert ID"
    content_after = "Link:"
    field_target  = "body"
    match_type    = "match_after"
  }

acknowledged_alert_id_field {
    name          = "Alert ID"
    content_after = "Link:"
    field_target  = "body"
    match_type    = "match_after"
  }

resolved_alert_id_field {
    name          = "Alert ID"
    content_after = "Link:"
    field_target  = "body"
    match_type    = "match_after"
  }

When I run apply I see the following;

 Error: PATCH https://betteruptime.com/api/v2/email-integrations/13293 returned 422: {"errors":{"cause_field.content":["is reserved"],"started_alert_id_field.content":["is reserved"],"acknowledged_alert_id_field.content":["is reserved"],"resolved_alert_id_field.content":["is reserved"]}}

Hi guys,

I am trying to make this work and facing response status code 401.

What could help me is option to allow "debug" and see plain http requests in console, including Bearer.

Support build-in log level error can be an option:

TF_LOG=ERROR terraform apply

EDIT: When I send api token empty, it behaves the same. What about to thrown specific error for this case?

I currently have terraform building my firewall rules, which pulls in needed information through terraform for the different providers I use. It would be great if BetterStack exposed it's ip ranges via a terraform data source.

For example, see cloudflare's ip_ranges: https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/data-sources/ip_ranges.html

Ideally some of the static data presented on this page would be useful:
https://betterstack.com/docs/uptime/frequently-asked-questions/#what-ips-does-better-uptime-use

Hi!

I would be great to have a data resource for betteruptime_incoming_webhook to be able to look up existing web hooks to pass on the URL of the incoming web hook to other resources. My use case is that we create incoming web hooks segmented by environment type (development, staging and production) and this works great. However we have more than one environment of the type production and I need to look up the existing web hook to pass on the URL to other resources, in this case a AWS SNS topic. Currently to solve this I first create the web hooks and then extract the URLs and put them into the .tfvars-file corresponding to those environments. This works but it would be nicer to be able to look up the existing web hook with a data resource to pass on to the other resource.

Hi,

I'm aware that there is currently no API to create a GCP Monitoring integration. However, I think I can make it work using the available webhook API and resource by configuring it for GCP. Do you happen to have an example laying around? What do you think of this solution? As far as I can tell this should work just fine.

Looks like there was a recent issue with incoming webhook integrations. I'm trying to import an existing email integration and receiving

Error: json: cannot unmarshal string into Go struct field emailIntegration.data.attributes.policy_id of type int

Hi,

I have a problem with the history field updating when it is already well defined.

My betteruptime_status_page_resource resource configuration:

resource "betteruptime_status_page_resource" "page_xorhak_io" {
    status_page_id = betteruptime_status_page.xorhak_page.id
    status_page_section_id  = betteruptime_status_page_section.xorhak_page_main.id
    resource_id = betteruptime_monitor.monitor_xorhak_io.id
    resource_type = "Monitor"
    public_name = "xorhak.io"
    history = "true"
    widget_type = "response_times"
    position = "1"
}

From a plan, this resource is updated (history):

# betteruptime_status_page_resource.page_xorhak_io will be updated in-place
~ resource "betteruptime_status_page_resource" "page_xorhak_io" {
  ~ history                = false -> true
    id                     = "164934"
    # (7 unchanged attributes hidden)
}

But this field is already defined to "true" (and it's good in the dashboard):

$ terraform state show betteruptime_status_page_resource.page_xorhak_io
# betteruptime_status_page_resource.page_xorhak_io:
resource "betteruptime_status_page_resource" "page_xorhak_io" {
    history                = true
    id                     = "164934"
    position               = 1
    public_name            = "xorhak.io"
    resource_id            = 682047
    resource_type          = "Monitor"
    status_page_id         = "142098"
    status_page_section_id = 123172
    widget_type            = "response_times"
}

But here the API request, the history field is false:

$ curl -s -X GET -H "Authorization: Bearer XXXXXXXXXXX" "https://betteruptime.com/api/v2/status-pages/142098/resources/164934" | jq -r '.data.attributes.history'
false

Any idea where is the problem?

Thanks

After creating a monitor resource, if the monitor is updated from the betteruptime dashboard, the next deployments start failing with error:

Error: PATCH https://betteruptime.com/api/v2/monitors/[MONITOR_ID] returned 422: {"errors":{"regions":["are not included in the list: us, eu, as, au"]}}

This can be replicated following the steps:

1. Create a monitor

   resource "betteruptime_monitor" "this" {
     url          = "https://example.com"
     monitor_type = "status"
   }

   This creates a monitor with regions: null. Which is perfectly fine.
   Deploying this multiple times works fine.

2. Now open your betteruptime dashboard and update "On call escalation" (region is not updated):

   

3. Now deployment starts failing with aforementioned error.

4. The tf plan shows the following change:

   ~ resource "betteruptime_monitor" "this" {
       ~ regions = [
             - "us",
             - "eu",
             - "as",
             - "au",
         ]
         ... // truncated
     }
   

5. I assume regions: [] is being sent in the PATCH HTTP call, which fails with 422 from betteruptime (as verified with Postman).

6. It should be regions: null in the Patch HTTP call. Even if we want this to fail, a user friendly message would be of greater help than a 422 error.

The error here is HTTP Patch call being sent with regions: [], which is not accepted by betteruptime and fails with 422.
It should either be a valid region array with atleast 1 region OR null.

I wish to disable the domain expiration check for various monitors we have configured. Unfortunately, it appears to not be possible to disable this check via Terraform once it has been set.

I receive the Domain expiration is invalid. Valid values are: [nil, 1, 2, 3, 7, 14, 30, 60] error no matter what I do.

• Omitting the property results in the error.
• Changing the value to the string "nil" results in the error.
• Changing the value to the number 0 results in the error.

It appears the only way to disable the check, is to manually edit the entries in the UI and then remove the line from the TF file.

The UI for Status Pages allows setting a "Custom Javascript", but the resource_status_page TF resource is missing the equivalent custom_js option.

User Story

As an owner using terraform to configure BetterUptime, I need to be able to specify the widget type, so Terraform doesn't arbitrarily decide what widget_type to use for me.

Background

• While on a sales call recently, it was disclosed that I could use Terraform to configure BetterUptime. I said cool, we use terraform at my company and I've been looking for an excuse to learn, so I went about implementing our BU instance using Terraform
• As I iterated, I discovered that the provider would update resources I hadn't changed. While all the values I did specify stayed the same, it would modify the setting for the widget_type attribute, changing my page resources from history to plain.
• I went to the documentation to identify the property I was missing in my config but there was nothing described that corresponded to the widget_type. I had to learn about widget_type through the API docs.
• Because of this bug, every time I add a new resource to my status page, I have to follow-up in the Web UI and manually set the widget_type value for each individual resource to maintain what I want displayed. Since this is an internal-use status page, it currently has 30 resources listed, which is a lot of manual clicking when you factor in having to expand UI components to even see the dropdown to change the value.

Version:

$ terraform version
Terraform v1.0.8
on linux_amd64
+ provider registry.terraform.io/betterstackhq/better-uptime v0.3.10

Steps to reproduce:

1. Create monitor with paused = false

resource "betteruptime_monitor" "bu_monitor" {
  url = "http://..."
  paused = false
  ...
}

2. Run terraform apply and confirm changes.

3. Change paused to true:

resource "betteruptime_monitor" "bu_monitor" {
  url = "http://..."
  paused = true
  ...
}

4. Run again terraform apply and confirm changes.

5. Run terraform plan/apply to see that paused status is not changed and Terraform wants to change it again.

Creating a status page with a custom logo results in state drift

resource "betteruptime_status_page" "example" {
  # other params
  logo_url                   = "https://mydomain.com/logo.png"

#terraform plan

  ~ resource "betteruptime_status_page" "example" {
        id                         = "123"
      ~ logo_url                   = "https://uptime-storage.s3.amazonaws.com/logos/123.png" -> "https://mydomain.com/logo.png"
    }

The only way to get around this is to create a lifecycle rule to ignore the logo_url, but the problem is we genuinely need to update the logo on the odd occasions.

Hey guys, I'm running into issues with your terraform provider, the type of widget on the status randomly resets and I have traced it down to the terraform provider resetting it for some reason

here's a snippet of the tf code and output when I plan the changes

resource "betteruptime_status_page_resource" "landing_page" {
  public_name = "Landing Page"
  widget_type = "history"

  resource_id            = betteruptime_monitor.landing_page.id
  resource_type          = "Monitor"
  status_page_id         = betteruptime_status_page.status_page.id
  status_page_section_id = betteruptime_status_page_section.app.id
}

And then when I plan or apply it gets changed to null:

 # betteruptime_status_page_resource.landing_page will be updated in-place
  ~ resource "betteruptime_status_page_resource" "landing_page" {
      - history                = true -> null
        id                     = "8308274"
        # (9 unchanged attributes hidden)
    }

Terraform v1.6.5 on darwin_arm64
+ provider registry.terraform.io/betterstackhq/better-uptime v0.4.0

While trying to extract a field using other_started_fields

other_started_fields {
    content_after = "START_TAG"
    content_before = "END_TAG"
    match_type     = "match_between"
    name           = "TestAttribute"
    field_target   = "body"
}

Results in the following

It's possible to configure a monitor with expected status codes via the web page.

original issue: BetterStackHQ/deprecated-terraform-provider-betteruptime#7

Using password for betteruptime_status_page causes Terraform to always set the password even though it has been previously applied and hasn't changed.

Output when terraform plan is run which has password:

Terraform used the selected providers to generate the following
execution plan. Resource actions are indicated with the following
symbols:
  ~ update in-place

Terraform will perform the following actions:

  # betteruptime_status_page.status_page will be updated in-place
  ~ resource "betteruptime_status_page" "status_page" {
        id                         = "123456"
      + password                   = "secret-password"
        # (10 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

We needed to add a lifecycle rule to avoid this on each run:

lifecycle {
  ignore_changes = [
    password
  ]
}

Our resource is created like this:

resource "betteruptime_status_page" "status_page" {
  company_name             = "Example ompany"
  company_url              = "https://www.examplecompany.com/"
  timezone                 = "wanted-zone"
  subdomain                = "subdomain"
  custom_domain            = "status.examplecompany.com"
  hide_from_search_engines = true
  subscribable             = true
  password_enabled         = true
  password                 = "secret-password"

  lifecycle {
    ignore_changes = [
      password
    ]
  }
}

From the API docs

• Status Pages Sections
• Metadata
• Escalation policies (requires API support first)

original issue: BetterStackHQ/deprecated-terraform-provider-betteruptime#5

There currently is no way to configure urgencies through Terraform, this makes working with escalation policies in Terraform less useful. Support for urgencies would greatly improve my workflow.

betteruptime_status_page.history has a hard minimum of 90 days, whereas it is possible to set it to 30 days in the web interface:

I am trying to create/modify/refresh resource betteruptime_status_page_resource, but I get an error:

  # betteruptime_status_page_resource.bu_resource will be created
  + resource "betteruptime_status_page_resource" "bu_resource" {
      + availability           = (known after apply)
      + id                     = (known after apply)
      + position               = 2276
      + public_name            = "********"
      + resource_id            = 12345
      + resource_type          = "Monitor"
      + status_history         = (known after apply)
      + status_page_id         = "12345"
      + status_page_section_id = 12345
      + widget_type            = "history"
    }

and I get an error:

Error: Invalid address to set: []string{"status_history", "0", "maintenance_duration"}

Configuration was working for months and stopped working on Jul 4th around 4 PM GMT.

It seems that something on API side was changed and now provider returns an error whatever I am trying to do with resource.

I am using Terraform 1.3.7, BetterUptime provider version 0.3.17.

I'm trying to create monitor with following provider

required_providers {
    betteruptime = {
      source = "BetterStackHQ/better-uptime"
      version = "0.5.1"
    }

terraform version

Terraform v1.7.1
on linux_amd64

error

POST https://betteruptime.com/api/v2/monitors returned 422: {"errors":{"resource_group":["doesn't exist"]}}

resource "betteruptime_monitor" "xx-xx" {

}

A follow up to #1 (comment).

original issue: BetterStackHQ/deprecated-terraform-provider-betteruptime#3

As the title states , the betteruptime_aws_cloudwatch_integration does not support to be paused using terraform.

I get the following message when applying configuration.

betteruptime_aws_cloudwatch_integration.backups: Modifying... [id=37769]
╷
│ Error: PATCH https://betteruptime.com/api/v2/aws-cloudwatch-integrations/37769 returned 422: {"errors":"Sorry, you misspe
lled some attributes","invalid_attributes":["paused"]}
│ 
│   with betteruptime_aws_cloudwatch_integration.backups,
│   on uptime_integration.tf line 1, in resource "betteruptime_aws_cloudwatch_integration" "backups":
│    1: resource "betteruptime_aws_cloudwatch_integration" "backups" {
│ 
╵