Alerts conditions API field names

This field allows you to scope a condition to either a JVM instance or to a whole application. This may be one of the strings:

• instance

• application

  Used for:

• Conditions

• Entity conditions

  For instance-based and JVM health metrics, see also violation_close_timer.

This is the status of your alert condition and is optional. The default is false.

This field may be used to enable or disable a condition for maintenance or testing periods.

Used for:

• Conditions
• External service conditions
• NRQL conditions
• Synthetic monitoring conditions

This is an array of entity IDs identifying the objects that will be monitored with your condition. These may be application IDs, browser IDs, key transaction IDs, external service IDs, etc.

These are entered as a series of comma-separated integers if there is more than one.

Used for:

• Conditions
• External service conditions

How long to wait, in seconds, after the last data point is received by our platform before considering the signal as lost. This is based on the time when data arrives and not on data timestamps. The default is null. Add a value to enable loss of signal detection.

Used for:

• NRQL conditions

When true, this closes all currently open incidents when no signal is heard within the expiration_duration time.

The default is false.

Used for:

• NRQL conditions

When true, this opens a loss of signal incident when there is no signal within the expiration_duration time.

The default is false.

Used for:

• NRQL conditions

This is the URL of the external service to be monitored. This string must not include the protocol. For example, use example.com, not https://example.com.

Used for:

• External service conditions

The metric field is used for three alert categories. The exact parameters available for use depend on the setting in the type field. These are listed below according to their alert type field.

This is the GUID of the Synthetic monitoring to alert on.

Used for:

• Synthetic monitoring conditions

This condition title will allow to you identify it in the UI.

Follow the guidelines for making this descriptive but short.

Used for:

• Conditions
• External service conditions
• NRQL conditions
• Synthetic monitoring conditions

This is the NRQL query that alerts monitors as part of a NRQL condition.

Used for:

• NRQL conditions

Deprecated in favor of an aggregation_method with either an aggregation_delay or aggregation_timer. This is the timeframe (in minutes) in which to evaluate the specified NRQL query. since_value must be between 1 and 20.

Used for:

• NRQL conditions

The runbook URL to display in notifications. This field is optional.

Used for:

• Conditions
• External service conditions
• NRQL conditions
• Synthetic monitoring conditions

The length of time in seconds to wait for the aggregation window to fill with data. Required when using CADENCE or EVENT_FLOW aggregation_method types. Default is 120 seconds.

Used with event flow and cadence aggregation methods.

Used for:

• NRQL conditions

New Relic aggregates data into windows, and needs to determine when the current window ends and the next one begins. The aggregation_method is the logic that tells us when we have all the data for a given aggregation window. Once the window is closed, the data is aggregated into a single point and evaluated against the threshold.

This field is optional. One of the following three values can be specified:

• EVENT_FLOW: (Default) Each aggregation window will wait until it starts to see timestamps arrive that are past its own delay setting. Once this occurs, the data is published. Relies on the timestamps of arriving data, so wall-clock time is no longer relevant. Works best for sources that come in frequently and with low event spread (high througput metrics).

• CADENCE: Classic New Relic logic where each evaluation window waits exactly as long as the aggregation_delay setting, using the wall-clock time as a timer. aggregation_delay is required when using this option. Data arriving too late will be dropped, which can cause false alerts.

• EVENT_TIMER: Each aggregation window has a timer on it, set to the aggregation_timer value. The timer starts running as soon as the first data point appears for that aggregation window (based on the data point’s timestamp). The aggregation_timer is reset for each new data point that arrives for that window. Once the aggregation_timer reaches 0, the aggregation window is published. Ideal for sparse and batched data, such as cloud integrations and infrequent error logs.

  The default is Event flow.

  Used for:

• NRQL conditions

The length of time in seconds to wait after each data point is received, to ensure the entire batch is processed. Required when using the EVENT_TIMER aggregation_method type. Default is 60 seconds.

Used for:

• NRQL conditions

Streaming alerts gather data together into specific amounts of time before running the function in the NRQL query. These windows of time are customizable.

Data points are collected together based on their timestamps and reported as a batch. The customizable aggregation window provides greater flexibility and fewer false incidents when alerting on irregular or less frequent data points.

In the UI, under Advanced signal settings, this is the Aggregation window field.

Default is 60 seconds. Maximum is 6 hours.

Used for:

• NRQL conditions

By default, aggregation windows are grouped sequentially. This can lead to spiky charts whenever one window starts and another begins.

Use slide_by to create sliding windows. Sliding aggregated windows overlap, creating smoother charts. The slide_by interval sets the duration of the overlap.

In the UI, under Advanced signal settings, click the Use sliding window aggregation toggle to enable sliding windows.

Default is based on the current window duration. The slide_by interval must divide evenly into your aggregation window duration. The slide_by interval must also be less than the window duration.

Deprecated in favor of an aggregation_method with either an aggregation_delay or aggregation_timer. The offset is how long we wait for late data before evaluating each aggregation window. Waiting longer gives a more accurate signal but increases latency. The default is 3 aggregation windows.

Used for:

• NRQL conditions

For sporadic data, you can avoid false alerts by filling the gaps (empty windows) with synthetic data.

• none: (Default) Use this if you don't want to take any action on empty aggregation windows. On evaluation, an empty aggregation window will reset the threshold duration timer. For example, if a condition says that all aggregation windows must have data points above the threshold for 5 minutes, and 1 of the 5 aggregation windows is empty, then the condition won't open an incident.

• static: Use this if you'd like to insert a custom static value into the empty aggregation windows before they're evaluated. This option has an additional, required parameter of fillValue that specifies what static value should be used. This defaults to 0.

• last_value: Use this to insert the last seen value before evaluation occurs. We maintain the state of the last seen value for 2 hours.

  In the UI, under Advanced signal settings, this is the Fill data gaps with field.

  Used for:

• NRQL conditions

This is the value used by the fill_option custom value. The default is 0.

Used for:

• NRQL conditions

This is the time (in minutes) for the condition to persist before triggering an event. It corresponds to the duration set when adding a threshold in the UI.

Used for:

• Conditions
• NRQL conditions

This field allows you to control the impact of an alert condition on the health status of the associated entity. To ensure that the associated entity's health status remains unchanged, even when alert incidents are triggered, set it to true. It corresponds to the Do not report system health status toggle when setting thresholds for alert conditions in the UI.

This determines what comparison will be used between the value_function and the terms[threshold] value to trigger an event. It corresponds to the operation selected when adding a threshold in the UI. It must be one of the following strings:

• above

• above_or_equals (NRQL conditions only)

• below

• below_or_equals (NRQL conditions only)

• equal

• not_equals (NRQL conditions only)

  Used for:

• Conditions

• External service conditions

• NRQL conditions

This corresponds to the severity level selected when setting the threshold values for the condition in the UI. This must be one of the following strings:

• critical

• warning

  Used for:

• Conditions

• External service conditions

• NRQL conditions

This is the threshold that the value_function must be compared to using the terms[operator] for an event to be triggered. It corresponds to the numeric value specified in the UI when adding the threshold values.

This is a numeric value and must be 0 (zero) or greater.

Used for:

• Conditions
• External service conditions
• NRQL conditions

This corresponds to the settings made in the UI when adding the threshold values. The choices are:

• all (corresponding to for at least in the UI)

• any (corresponding to at least once in in the UI)

  Used for:

• Conditions

• External service conditions

• NRQL conditions

This defines the type of metric that will be used for the alert. Allowable content for the metric field depends on the type value chosen.

There are two product categories :

This is the name of a user defined custom metric to be used to determine if an event should be triggered.

The user_defined[value_function] associated with the metric is compared with the terms[threshold] value when evaluating if an incident should be triggered. The comparison is performed using the operator defined by terms[operator].

Used for:

• Conditions
• External service conditions
• Synthetic monitoring conditions

This is the numeric value obtained from the custom metric specified by user_defined[metric].

It is compared with the terms[threshold] value when evaluating if an incident should be triggered. The comparison is performed using the operator defined by terms[operator].

One of these value functions must be specified:

• average

• min

• max

• total

• sample_size

  Used for:

• Conditions

When used for a NRQL condition, the options are:

• single_value (condition is evaluated based on each query's returned value)
• sum (condition is evaluated based on the sum of each query's returned values over the specified duration)

Use to automatically close instance-based incidents after the number of seconds specified.

Default is 259,200 seconds (3 days). Maximum is 30 days.

Used for:

• Location conditions
• NRQL conditions

Use to automatically close instance-based incidents, including JVM health metric incidents, after the number of hours specified. Must be between 1 and 720 hours. Defaults to 72 hours.

Used for:

• apm_app_metric (with condition_scope set to instance)

• apm_jvm_metric