Skip to main content
GET
Get alert rule

Authorizations

Authorization
string
header
required

Use an Observe API key from the management console. The key selects the project and must grant the permission listed on the operation. Keep this key on your server.

Path Parameters

alertRuleID
string
required

Alert rule ID (format aru-<number>).

Response

Alert rule.

id
string
required

Alert rule ID (format aru-<number>).

name
string
required
ruleType
enum<string>
required
Available options:
login_success_rate
rule
object
required

The configuration of an alert rule: the generic envelope every rule type shares, plus one settings object belonging to the rule type named by type. Everything outside settings is implemented once, generically - the window is resolved and handed to the rule type as two absolute timestamps, and the conditions are applied to whatever number the rule type returned, so a rule type never sees the thresholds. Shape and vocabulary are validated here. The semantics that span fields - that the bands get stricter as the level does, that recovery sits on the lenient side of them, that the window is a whole number of days, and that groupBy names dimensions this project actually has - are validated when the rule is saved and again when it is evaluated, because only the second catches a project that changed after the rule was written.

contactPointID
string
required

Alert contact point ID (format acp-<number>) this rule notifies.

contactPointName
string
required

Name of the contact point this rule notifies, resolved from contactPointID so a rule can be displayed without a second request. Display-only - requests still reference the contact point by contactPointID.

status
enum<string>
required
Available options:
active,
paused
instanceTotals
object
required

How many of a rule's alert instances sit in each status, counted over all of them rather than over a page of them. This is what lets a rule row say "2 of 12 firing" without the client reading a single instance - and what keeps that number from quietly becoming "2 of however many were fetched" once a rule groups into more instances than one page holds. Every field is present, zero included, so a client can render the set without checking which keys exist. Counts include every instance the rule currently has.

createdMs
integer<int64>
required
updatedMs
integer<int64>
required
description
string
labels
object
lastEvaluatedMs
integer<int64>

When the evaluation runner last attempted this rule, successfully or not. Absent means it has never been attempted, which every rule is for up to one evaluation interval after it is created or edited - a state worth showing rather than rendering as healthy.

lastErrorReason
enum<string>

Why the last evaluation attempt failed, absent when it succeeded. This is rule health, which is a different question from whether anything the rule watches is breaching: a rule here is not evaluating at all, so it is neither firing nor all-clear. An unclassified failure reports evaluation_failed rather than a value outside this list.

Available options:
rule_type_not_implemented,
config_invalid,
series_not_available,
dimension_not_available,
too_many_instances,
evaluation_failed
lastErrorMessage
string

The detail behind lastErrorReason, truncated for display. Absent when the last attempt succeeded.