diff --git a/website/docs/r/alert_condition.html.markdown b/website/docs/r/alert_condition.html.markdown
index 9b3fabf95..83add0492 100644
--- a/website/docs/r/alert_condition.html.markdown
+++ b/website/docs/r/alert_condition.html.markdown
@@ -10,7 +10,7 @@ description: |-
Use this resource to create and manage alert conditions for APM, Browser, and Mobile in New Relic.
--> **NOTE:** This is a legacy resource. The [newrelic_nrql_alert_condition](nrql_alert_condition.html) resource is preferred for configuring alerts conditions. In most cases feature parity can be achieved with a NRQL query. This condition type may be deprecated in the future.
+-> **WARNING:** The `newrelic_alert_condition` resource is deprecated and will be removed in the next major release. The resource [newrelic_nrql_alert_condition](nrql_alert_condition.html) would be a preferred alternative to configure alert conditions - in most cases, feature parity can be achieved with a NRQL query.
## Example Usage
diff --git a/website/docs/r/infra_alert_condition.html.markdown b/website/docs/r/infra_alert_condition.html.markdown
index 9bb2a03c9..843534ff0 100644
--- a/website/docs/r/infra_alert_condition.html.markdown
+++ b/website/docs/r/infra_alert_condition.html.markdown
@@ -10,7 +10,7 @@ description: |-
Use this resource to create and manage Infrastructure alert conditions in New Relic.
--> **NOTE:** This is a legacy resource. The [newrelic_nrql_alert_condition](nrql_alert_condition.html) resource is preferred for configuring alerts conditions. In most cases feature parity can be achieved with a NRQL query. This condition type may be deprecated in the future.
+-> **WARNING:** The `newrelic_infra_alert_condition` resource is deprecated and will be removed in the next major release. The resource [newrelic_nrql_alert_condition](nrql_alert_condition.html) would be a preferred alternative to configure alert conditions - in most cases, feature parity can be achieved with a NRQL query.
## Example Usage
diff --git a/website/docs/r/monitor_downtime.html.markdown b/website/docs/r/monitor_downtime.html.markdown
index e65c6c6f8..e1ea3f7a4 100644
--- a/website/docs/r/monitor_downtime.html.markdown
+++ b/website/docs/r/monitor_downtime.html.markdown
@@ -8,7 +8,7 @@ description: |-
# Resource: newrelic\_monitor\_downtime
-Use this resource to create, update, and delete Monitor Downtimes in New Relic.
+Use this resource to create, update, and delete [Monitor Downtimes](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/monitor-downtimes-disable-monitoring-during-scheduled-maintenance-times/) in New Relic.
## Example Usage
@@ -21,52 +21,52 @@ resource "newrelic_monitor_downtime" "foo" {
]
mode = "WEEKLY"
start_time = "2023-11-30T10:30:00"
- end_time = "2023-12-10T10:30:00"
+ end_time = "2023-12-10T02:45:30"
time_zone = "Asia/Kolkata"
end_repeat {
on_date = "2023-12-20"
}
maintenance_days = [
- "MONDAY",
- "TUESDAY",
+ "FRIDAY",
+ "SATURDAY",
]
}
```
-Monitor Downtimes are of four types; once, daily, weekly and monthly. For more details on each type and the right arguments that go with them, check out the [argument reference][#argument-reference] and [examples](#examples) sections below.
+Monitor Downtimes are of four types; **one-time**, **daily**, **weekly** and **monthly**. For more details on each type and the right arguments that go with them, check out the [argument reference](#argument-reference) and [examples](#examples) sections below.
## Argument Reference
### Arguments Common To All Four Types of Monitor Downtimes
-* `account_id`- (Optional) The account in which the monitor downtime would be created. Defaults to `NEW_RELIC_ACCOUNT_ID` in the environment, if not specified.
+* `account_id`- (Optional) The account in which the monitor downtime would be created. Defaults to the value of the environment variable `NEW_RELIC_ACCOUNT_ID` (or the `account_id` specified in the `provider{}`), if not specified.
* `name` - (Required) Name of the monitor downtime to be created.
-* `mode` - (Required) One of the four modes of operation of Monitor Downtimes - `ONE_TIME`, `DAILY`, `MONTHLY` or `WEEKLY`.
-* `monitor_guids` - (Optional) A list of GUIDs of monitors the Monitor Downtime would need to be applied to.
-* `start_time` - (Required) The time at which the Monitor Downtime would begin to operate, a timestamp specified in the ISO 8601 format without the offset - for instance, `2023-12-04T14:27:07`.
-* `end_time` - (Required) The time at which the Monitor Downtime would end operating, a timestamp specified in the ISO 8601 format without the offset - for instance, `2023-12-04T14:27:07`.
-* `timezone` - (Required) The timezone in which timestamps `start_time` and `end_time` have been specified. Valid timezones which may be specified with this argument can be found in this [list](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List), in the column '**TZ identifier**'.
+* `mode` - (Required) One of the four modes of operation of monitor downtimes - `ONE_TIME`, `DAILY`, `MONTHLY` or `WEEKLY`.
+* `monitor_guids` - (Optional) A list of GUIDs of synthetic monitors the monitor downtime would need to be applied to.
+* `start_time` - (Required) The time at which the monitor downtime would begin to operate, a timestamp specified in the ISO 8601 format without the offset/timezone - for instance, `2023-12-20T10:48:53`.
+* `end_time` - (Required) The time at which the monitor downtime would end operating, a timestamp specified in the ISO 8601 format without the offset/timezone - for instance, `2024-01-05T14:27:07`.
+* `timezone` - (Required) The timezone in which timestamps `start_time` and `end_time` have been specified. Valid timezones which may be specified with this argument can be found in this [list](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List), under the column '**TZ identifier**'.
### Arguments Specific Only to Certain Types of Monitor Downtimes
-The following arguments go only with certain types of monitor downtimes, and are hence, optional, at a resource schema level. However, some of these are required to be specified with certain types of monitor downtimes - please see notes adjoining arguments in the list below.
+The following arguments go only with certain types of monitor downtimes, and are hence, optional, at a resource schema level. However, _some of these_ are **required** to be specified with certain types of monitor downtimes - please see notes adjoining arguments in the list below, and [examples](#examples) to obtain an understanding of the usage of apt arguments with each type of monitor downtimes.
* `end_repeat` - Options which may be used to specify when the repeat cycle of the monitor should end. This argument comprises the following nested arguments -
- * `on_date` - The date on which the monitor downtime's repeat cycle would need to come to an end, a string in "DDDD-MM-YY" format.
+ * `on_date` - The date on which the monitor downtime's repeat cycle would need to come to an end, a string in `DDDD-MM-YY` format.
* `on_repeat` - An integer that specifies the number of occurrences, after which the monitor downtime's repeat cycle would need to come to an end.
-> **NOTE:** `end_repeat` **can only be used with the modes** `DAILY`, `MONTHLY` and `WEEKLY` and **is an optional argument** when monitor downtimes of these modes are created. Additionally, **either** `on_date` or `on_repeat` **are required to be specified with** `end_repeat`, but not both, as `on_date` and `on_repeat` are mutually exclusive.
-* `maintenance_days` - A list of days on which monthly monitor downtimes would function. Valid values which go into this list would be `"SUNDAY"`, `"MONDAY"`, `"TUESDAY"`, `"WEDNESDAY"`, `"THURSDAY"`, `"FRIDAY"` and/or `"SATURDAY"`.
+* `maintenance_days` - A list of days on which weekly monitor downtimes would function. Valid values which go into this list would be `"SUNDAY"`, `"MONDAY"`, `"TUESDAY"`, `"WEDNESDAY"`, `"THURSDAY"`, `"FRIDAY"` and/or `"SATURDAY"`.
--> **NOTE:** `maintenance_days` **can only be used with the mode** `MONTHLY`, and **is a required argument** with weekly monitor downtimes (if the `mode` is `WEEKLY`).
+-> **NOTE:** `maintenance_days` **can only be used with the mode** `WEEKLY`, and **is a required argument** with weekly monitor downtimes (i.e. if the `mode` is `WEEKLY`).
* `frequency` - Options which may be used to specify the configuration of a monthly monitor downtime. This argument comprises the following nested arguments -
- * `days_of_month` - A list of integers, specifying the days of a month on which the monthly monitor downtime would function.
+ * `days_of_month` - A list of integers, specifying the days of a month on which the monthly monitor downtime would function, e.g. [3, 6, 14, 23].
* `days_of_week` - An argument that specifies a day of a week and its occurrence in a month, on which the monthly monitor downtime would function. This argument, further, comprises the following nested arguments -
* `week_day` - A day of the week (one of `"SUNDAY"`, `"MONDAY"`, `"TUESDAY"`, `"WEDNESDAY"`, `"THURSDAY"`, `"FRIDAY"` or `"SATURDAY"`).
* `ordinal_day_of_month` - The occurrence of `week_day` in a month (one of `"FIRST"`, `"SECOND"`, `"THIRD"`, `"FOURTH"`, `"LAST"`).
--> **NOTE:** `frequency` **can only be used with the mode** `WEEKLY`, and **is a required argument** with monthly monitor downtimes (if the `mode` is `MONTHLY`). Additionally, **either** `days_of_month` or `days_of_week` **are required to be specified with** `frequency`, but not both, as `days_of_month` and `days_of_week` are mutually exclusive. If `days_of_week` is specified, values of **both** of its nested arguments, `week_day` and `ordinal_day_of_month` **would need to be specified** too.
+-> **NOTE:** `frequency` **can only be used with the mode** `MONTHLY`, and **is a required argument** with monthly monitor downtimes (if the `mode` is `MONTHLY`). Additionally, **either** `days_of_month` or `days_of_week` **are required to be specified with** `frequency`, but not both, as `days_of_month` and `days_of_week` are mutually exclusive. If `days_of_week` is specified, values of **both** of its nested arguments, `week_day` and `ordinal_day_of_month` **would need to be specified** too.
## Attributes Reference
@@ -78,7 +78,7 @@ The following attributes are exported:
### One-Time Monitor Downtime
-The below example illustrates creating a 'one-time' monitor downtime.
+The below example illustrates creating a **one-time** monitor downtime.
```hcl
resource "newrelic_monitor_downtime" "sample_one_time_newrelic_monitor_downtime" {
@@ -89,16 +89,16 @@ resource "newrelic_monitor_downtime" "sample_one_time_newrelic_monitor_downtime"
]
mode = "ONE_TIME"
start_time = "2023-12-04T10:15:00"
- end_time = "2024-01-04T10:15:00"
+ end_time = "2024-01-04T16:24:30"
time_zone = "America/Los_Angeles"
}
```
### Daily Monitor Downtime
-The below example illustrates creating a 'daily' monitor downtime.
+The below example illustrates creating a **daily** monitor downtime.
-Note that `end_repeat` has been specified in the configuration; however, this is optional, in accordance with the rules of `end_repeat` specified in the [argument reference][#argument-reference] section above.
+Note that `end_repeat` has been specified in the configuration; however, this is optional, in accordance with the rules of `end_repeat` specified in the [argument reference](#argument-reference) section above. This example uses the `on_date` nested argument of `end_repeat`, however, the other nested argument, `on_repeat` may also be used _instead_, as you may see in some of the other examples below; though both `on_date` and `on_repeat` cannot be specified together, as they are mutually exclusive.
```hcl
resource "newrelic_monitor_downtime" "sample_daily_newrelic_monitor_downtime" {
@@ -109,7 +109,7 @@ resource "newrelic_monitor_downtime" "sample_daily_newrelic_monitor_downtime" {
]
mode = "DAILY"
start_time = "2023-12-04T18:15:00"
- end_time = "2024-01-04T18:15:00"
+ end_time = "2024-01-04T07:15:00"
end_repeat {
on_date = "2023-12-25"
}
@@ -119,9 +119,9 @@ resource "newrelic_monitor_downtime" "sample_daily_newrelic_monitor_downtime" {
### Weekly Monitor Downtime
-The below example illustrates creating a 'weekly' monitor downtime.
+The below example illustrates creating a **weekly** monitor downtime.
-Note that `maintenance_days` has been specified in the configuration as it is required with weekly monitor downtimes; and `end_repeat` has not been specified as it is optional, all in accordance with the rules of these arguments specified in the [argument reference][#argument-reference] section above.
+Note that `maintenance_days` has been specified in the configuration as it is required with weekly monitor downtimes; and `end_repeat` has not been specified as it is optional, all in accordance with the rules of these arguments specified in the [argument reference](#argument-reference) section above.
```hcl
resource "newrelic_monitor_downtime" "sample_weekly_newrelic_monitor_downtime" {
@@ -132,7 +132,7 @@ resource "newrelic_monitor_downtime" "sample_weekly_newrelic_monitor_downtime" {
]
mode = "WEEKLY"
start_time = "2023-12-04T14:15:00"
- end_time = "2024-01-04T14:15:00"
+ end_time = "2024-01-04T23:55:00"
time_zone = "US/Hawaii"
maintenance_days = [
"SATURDAY",
@@ -143,9 +143,9 @@ resource "newrelic_monitor_downtime" "sample_weekly_newrelic_monitor_downtime" {
### Monthly Monitor Downtime
-The below example illustrates creating a monthly monitor downtime.
+The below example illustrates creating a **monthly** monitor downtime.
-Note that `frequency` has been specified in the configuration as it is required with monthly monitor downtimes, and `end_repeat` has been specified too, though it is optional, all in accordance with the rules of these arguments specified in the [argument reference][#argument-reference] section above.
+Note that `frequency` has been specified in the configuration as it is required with monthly monitor downtimes, and `end_repeat` has been specified too, though it is optional. `frequency` has been specified with `days_of_week` comprising both of its nested arguments, `ordinal_day_of_month` and `week_day`; all in accordance with the rules of these arguments specified in the [argument reference](#argument-reference) section above.
```hcl
resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime" {
@@ -156,7 +156,7 @@ resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime"
]
mode = "MONTHLY"
start_time = "2023-12-04T07:15:00"
- end_time = "2024-01-04T07:15:00"
+ end_time = "2024-01-04T19:15:00"
end_repeat {
on_repeat = 6
}
@@ -169,7 +169,26 @@ resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime"
}
}
```
-
+However, the `frequency` block in monthly monitor downtimes may also be specified with its other nested argument, `days_of_month`, as shown in the example below - though both `days_of_month` and `days_of_week` cannot be specified together, as they are mutually exclusive.
+```hcl
+resource "newrelic_monitor_downtime" "sample_monthly_newrelic_monitor_downtime" {
+ name = "Sample Monthly Monitor Downtime"
+ monitor_guids = [
+ "",
+ "",
+ ]
+ mode = "MONTHLY"
+ start_time = "2023-12-04T07:15:00"
+ end_time = "2024-01-04T19:15:00"
+ end_repeat {
+ on_repeat = 6
+ }
+ time_zone = "Europe/Dublin"
+ frequency {
+ days_of_month = [3, 6, 14, 23]
+ }
+}
+```
## Import
A monitor downtime can be imported into Terraform configuration using its `guid`, i.e.
diff --git a/website/docs/r/synthetics_alert_condition.html.markdown b/website/docs/r/synthetics_alert_condition.html.markdown
index 0023d6ae8..d9f571e91 100644
--- a/website/docs/r/synthetics_alert_condition.html.markdown
+++ b/website/docs/r/synthetics_alert_condition.html.markdown
@@ -10,7 +10,7 @@ description: |-
Use this resource to create and manage synthetics alert conditions in New Relic.
--> **NOTE:** This is a legacy resource. The [newrelic_nrql_alert_condition](nrql_alert_condition.html) resource is preferred for configuring alerts conditions. In most cases feature parity can be achieved with a NRQL query. This condition type may be deprecated in the future.
+-> **WARNING:** The `newrelic_synthetics_alert_condition` resource is deprecated and will be removed in the next major release. The resource [newrelic_nrql_alert_condition](nrql_alert_condition.html) would be a preferred alternative to configure alert conditions - in most cases, feature parity can be achieved with a NRQL query.
## Example Usage