Skip to main content
POST
Create alert rule (V2)

Restrictions

Usage

  • folder_id, name, ds_type, enabled, cron_pattern and rule_configs.queries are required, and at least one of ds_list (wildcards supported) or ds_ids must be non-empty.
  • enabled must be passed explicitly (including false); omitting it returns InvalidParameter.
  • folder_id must be an existing folder (otherwise InvalidParameter) and the caller must be able to manage the folder (account owner or admin, creator of the folder or one of its ancestors, or member of the team bound to the folder or an ancestor) (otherwise AccessDenied).
  • name must be unique within folder_id; a duplicate returns InvalidParameter.
  • When enabled is true, ds_type must be a datasource type that supports alerting and every ID in ds_ids must be an enabled datasource with alerting turned on; otherwise the call returns InvalidParameter.
  • Callers other than the account owner or admins need read-only access to every datasource listed in ds_ids or currently matched by ds_list; otherwise the call returns AccessDenied (no permission to reference datasource "<name>").
  • The call fails with AccessDenied when creating the rule would exceed the account’s alert rule license limit.
  • id, account_id, creator_*, updater_*, created_at, and updated_at are assigned by the server; client-supplied values are ignored.
  • channel_ids can be empty; alerts will then route through the global integration.
  • The request body may not exceed 1 MiB; a larger body returns HTTP 413 (EntityTooLarge). Additional unknown fields are ignored (forward compatibility).
  • Every call is recorded in the account audit log. Don’t put secrets in request fields.

Authorizations

app_key
string
query
required

APP Key created in the Flashduty console under My → APP Key. Send it as the app_key query parameter or in the Fd-App-Key request header. Its effective access is the intersection of the key's permission scope and the creator's current role permissions. Keep it secret.

Body

application/json

Complete V2 alert rule configuration. The core difference from V1 lives in rule_configs: the three checkers describe recovery and ending semantics with the lifecycle v2 recovery_mode/end_mode enums.

folder_id
integer<uint64>
required

ID of the folder the rule belongs to; list folders via POST /monit/folder/list. Cannot be changed through the update API — use /monit/rule/move instead.

name
string
required

Rule name. Must be unique within the folder and at most 128 characters.

ds_type
string
required

Datasource type the rule queries. When the rule is enabled it must be a type that supports alerting: prometheus, elasticsearch, loki, clickhouse, mysql, oracle, postgres, sls, tencent_cls, victorialogs.

enabled
boolean
required

Whether the rule is enabled. Required — the server enforces an explicit value (including false) while decoding. Setting it to false on update clears the rule's active alerts.

rule_configs
object
required

Detection configuration: query list plus trigger/recovery conditions. See AlertRuleConfigsV2.

cron_pattern
string
required

Schedule expression: a 6-field cron with seconds (e.g. 0 * * * * *), a descriptor such as @hourly, or @every <duration> with a whole number of seconds of at least 1s (e.g. @every 30s). Must not start with CRON_TZ= or TZ=; set the timezone in the timezone field instead.

id
integer<uint64>

Rule ID. Required on update; omit on create (assigned by the server).

account_id
integer<uint64>

Account ID, filled by the server from the authentication context; any client-supplied value is ignored.

labels
object

Custom labels added to every alert event of the rule. Keys are trimmed, must not be empty and must not start with __alert_rule_ (reserved); values containing {{ are rendered as templates when events are delivered; job and instance values are limited to 255 characters. The serialized object may not exceed 1024 characters.

ds_list
string[]

Datasource name match patterns (wildcards supported). At least one of ds_list / ds_ids must be non-empty; both are merged to decide which datasources the rule monitors.

ds_ids
integer<uint64>[]

Datasource ID list, merged with ds_list to decide the monitored datasources; IDs survive datasource renames. At least one of ds_list / ds_ids must be provided.

debug_log_enabled
boolean

Enable debug logging; the edge then emits detailed evaluation logs for this rule, useful when the rule does not trigger as expected.

timezone
string
default:Asia/Shanghai

Timezone the rule runs in; it decides how the cron schedule and enabled time windows are interpreted. Only IANA names are accepted (e.g. Asia/Shanghai, UTC, Europe/London); abbreviations or offsets like Local, UTC+8, CST are rejected. Empty falls back to Asia/Shanghai.

delay_seconds
integer

Seconds the evaluation query window is shifted back, compensating for data ingestion latency.

enabled_times
object[]

Time windows during which the rule is in effect. When omitted or empty, the rule is active 00:00–23:59 every day.

annotations
object

Extra annotation key-value pairs delivered with alert events; keys must not start with $ (reserved for query fields).

description_type
enum<string>
default:text

Format of the description content. Empty or omitted defaults to text. text = plain text; markdown = Markdown, rendered as such in alert details.

Available options:
text,
markdown
description
string

Rule description; rendered as plain text or Markdown according to description_type.

channel_ids
integer<uint64>[]

Collaboration space IDs alerts are sent to. May be empty; alerts then route through the global integration.

repeat_interval
integer<int64>

Notification repeat interval in seconds. Values below 1 fall back to the default 3600; maximum 2147483647.

repeat_total
integer<int64>

Maximum number of repeat notifications. Values below 1 fall back to the default 3; maximum 2147483647.

investigation_targets
object[]

Drill-down entries linked from the alert event detail page; at most 20 items, duplicates rejected, and at most 32 KiB once serialized. On update the field is presence-based: omit it to keep the current value, pass [] to clear; null is rejected.

Maximum array length: 20
creator_id
integer<uint64>

Creator member ID, filled by the server from the current user; any client-supplied value is ignored.

creator_name
string

Creator name, filled by the server; any client-supplied value is ignored.

updater_id
integer<uint64>

ID of the member who last updated the rule, filled by the server; any client-supplied value is ignored.

updater_name
string

Name of the member who last updated the rule, filled by the server; any client-supplied value is ignored.

created_at
integer<int64>

Creation time as a Unix timestamp in seconds, generated by the server; any client-supplied value is ignored.

updated_at
integer<int64>

Last update time as a Unix timestamp in seconds, generated by the server; any client-supplied value is ignored.

Response

Success

Success response envelope. On every 2xx response, request_id identifies the call (also mirrored in the Flashcat-Request-Id header) and data holds the endpoint-specific payload. Failure responses use a different shape — see ErrorResponse.

request_id
string
required

Unique ID for this request. Mirrored in the Flashcat-Request-Id response header. Include it when reporting issues.

Example:

"01HK8XQE3Z7JM2NTFQ5YJ8P9R4"

data
object

Complete V2 alert rule configuration. The core difference from V1 lives in rule_configs: the three checkers describe recovery and ending semantics with the lifecycle v2 recovery_mode/end_mode enums.