Update alert rule
Replace the full configuration of an existing alert rule. All fields are overwritten.
Restrictions
| Aspect | Value |
|---|---|
| Rate limits | 1,000 requests/minute; 50 requests/second per account |
| Permissions | Alerting Rules Manage (monit) |
Usage
idis required. All other fields follow the same rules asPOST /monit/rule/create.- Every call is recorded in the account audit log. Don’t put secrets in request fields.
Authorizations
App key issued from the Flashduty console under Account → APP Keys. Required on every public API call. Keep it secret — it grants the same access as the owning account.
Body
Full alert rule configuration.
Folder the rule belongs to.
Rule name.
Custom labels.
Data source type.
Data source name patterns (supports wildcards).
Specific data source IDs.
Rule evaluation configuration.
5-field cron schedule. Must not start with CRON_TZ= or TZ=; use the timezone field instead.
Timezone in which the rule executes. Determines how the cron schedule and effective time windows are interpreted. Only IANA timezone names are accepted (e.g. Asia/Shanghai, UTC, Europe/London); shortcuts and offsets such as Local, UTC+8, or CST are rejected. Treated as Asia/Shanghai if empty.
Time windows when the rule is active.
text, markdown Channel IDs to send alerts to.
Notification repeat interval in seconds.
Max number of repeat notifications.
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.