Alert policies

Turn check failures into notifications: conditions, channels, escalation and anti-flap delay.

What it's for

An alert policy decides when and how you are notified. It links a set of conditions (e.g. a failing check) to one or more notification channels, with an optional escalation and an anti-flap delay (cooldown) to avoid spam.

The policy model

Field	Type	Required	Description
`id`	uuid	(generated)	Unique identifier.
`name`	string	✅	Policy name.
`conditions`	JSON object/array	—	Trigger conditions (severity, check type, targeted hosts…).
`channels`	JSON object/array	—	Notification channels (email, etc.).
`escalation`	JSON object/array	—	Escalation rules (e.g. notify a second level after X minutes).
`enabled`	boolean	—	`true` by default.
`cooldown_sec`	integer	—	Minimum delay between two notifications for the same cause.
`created_at` / `updated_at`	date	(managed)	Timestamps.

The conditions, channels and escalation fields are JSON structures: their exact shape depends on your configuration. The portal provides a guided editor; through the API, you pass the JSON directly.

Using it from the portal

The Alert policies section lists your policies. You can create, edit, enable/disable and delete a policy, define its conditions, choose its channels and configure escalation.

Listing and viewing: all roles. Create, edit, delete: owner and admin.

Using it through the API

List

GET /api/v2/alert-policies

curl -s https://api.secumon.secuaas.ovh/api/v2/alert-policies \
  -H "Authorization: Bearer $SECUMON_TOKEN"

{
  "count": 1,
  "policies": [
    {
      "id": "7c6d5e4f-1111-4222-9333-444455556666",
      "name": "Critical → on-call",
      "enabled": true,
      "cooldown_sec": 300
    }
  ]
}

Create

POST /api/v2/alert-policies — name required.

curl -s -X POST https://api.secumon.secuaas.ovh/api/v2/alert-policies \
  -H "Authorization: Bearer $SECUMON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Critical → on-call",
    "conditions": { "severity": ["critical"] },
    "channels": { "email": ["oncall@example.com"] },
    "escalation": { "after_minutes": 15, "notify": ["lead@example.com"] },
    "cooldown_sec": 300
  }'

Response: 201 Created with the full policy.

View, edit, delete

# Detail
curl -s https://api.secumon.secuaas.ovh/api/v2/alert-policies/7c6d5e4f-1111-4222-9333-444455556666 \
  -H "Authorization: Bearer $SECUMON_TOKEN"

# Edit (name required)
curl -s -X PUT https://api.secumon.secuaas.ovh/api/v2/alert-policies/7c6d5e4f-1111-4222-9333-444455556666 \
  -H "Authorization: Bearer $SECUMON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Critical → on-call", "enabled": false, "cooldown_sec": 600 }'

# Delete
curl -s -X DELETE https://api.secumon.secuaas.ovh/api/v2/alert-policies/7c6d5e4f-1111-4222-9333-444455556666 \
  -H "Authorization: Bearer $SECUMON_TOKEN"

Deletion returns 204 No Content. An unknown policy returns 404.

Use cases

Filter by severity: only notify on-call for critical incidents, and route warning to a less intrusive channel.
Escalation: alert a second level if an incident is not acknowledged after 15 minutes.
Anti-flap: set a high cooldown_sec on a target known to "flap", to avoid a burst of notifications.

Tips

Combine your policies with on-call schedules: the policy decides what to notify, the on-call schedule decides who is on duty.
Disable (enabled: false) a policy during an intervention rather than deleting it, so you can re-enable it afterward unchanged.
During a maintenance window, alerts can be suspended automatically — there is no need to disable your policies by hand.

On this page