Event policies

Test → Events → Event policies are ordered rules that decide what happens when an event opens or reopens: mute warnings at night, send payment criticals to Slack and escalate to SMS when nobody acks, cut notices during a maintenance window, deduplicate ignoring the host, resolve by itself after a while.

#How it works

1. An event opens or reopens (a plain repeat does not run the policies again).
2. The enabled policies are tried in list order. The actions of a policy whose conditions match are applied.
3. With Stop here on (the default) later policies are not looked at; with it off, the next matching policies apply too.
4. What was done is written to the Policy trail on the event page: the policy's name, version, the action and its detail.

Change the order by dragging a row or with the arrow buttons. A disabled policy keeps its place but is not applied. Any workspace member can add and change policies; every change goes to the version history and the audit log.

#Built-in policies and your policies

The rules on the Built-in policies tab (Kubernetes, Docker, Linux, Windows, network devices) are on from the install and open events with the source spitfire.builtin from metrics; you change their thresholds and channels there. The policies on the Your policies tab decide what happens to every event that opens, the built-in ones included. The tabs show the on and total counts, e.g. Built-in policies (32 on / 32); the number next to Event policies in the side menu is the sum of both that are on.

#Start from a template

1. On the Your policies tab press New policy.
2. Pick a Start from a template card (search box and categories, with their template counts): Blank policy, Built-in rule events (an area's or one rule's events, e.g. builtin.k8s.*), Notification, Noise reduction, Lifecycle.
3. The conditions and actions are filled in. For actions that need a channel (route, escalate, tracker), pick it.
4. Press Save.

Check: the policy shows in the list and the tab's on count goes up by one.

#Conditions

An empty field means "any". Every filled field must match; one of a field's values is enough.

Each list takes up to 20 values.

#Time window

Presets: Business hours (Mon–Fri 09:00–18:00), Outside business hours (outside that window), Night (every day 22:00–07:00) and Weekend (Sat–Sun). When the start is later than the end the window crosses midnight. The time zone is filled with your browser's (like Europe/Istanbul); you can change it.

#Actions

A policy has 1–12 actions, at most one of each type.

#Notices, escalation and renotify

The notice plan a route sets shows on the event page: which policy, which channels, which step it is on and when the next action is. Ack or resolve stops the plan. Escalation steps are 1–1440 minutes and must increase; renotify is 5–1440 minutes, auto-resolve 5–10080 minutes (7 days).

#Signed ack / resolve links

With Settings → General → Public address set, problem notices (e-mail, Slack, Teams, SMS, JSON) carry Ack and Resolve links. A link needs no sign-in, is valid for 7 days and works once; the timeline shows it as "by link". JSON webhooks get them in eventLinks (ackUrl, resolveUrl, eventUrl).

#Try (dry run)

Try in the editor runs the policy over the last 7 days of events without saving it: how many events were looked at (up to 5000), how many matched, how many each action would touch and up to 20 samples (with the severity change and the trail). Nothing changes and no notice goes out.

#Version history

Every save, enable / disable and delete writes a new version. A policy's History button on the list shows the versions with who changed what and when. When two people edit the same policy at once the second save is refused: reload the page and save again.

#Drop

Drop is off by default. A workspace admin can turn it on with Allow drop at the top of the page. While it is off, a policy with a drop action still stores the event and suppresses it (drop_off in the trail). A dropped event does not show in the list, the counters or a timeline, and cannot be brought back. Prefer suppress when you can.

#Correlation

The Correlate action puts events with one cause in one group, for example disk, CPU and service alerts from the same host within a few minutes.

1. Under Same values of, tick the fields that make the group: service, host, environment, resource, source, type; tag keys too if you like (comma separated). The default is service + environment.
2. Enter the window in minutes (1–1440, default 10).
3. Add a Route action to the same policy: the group's notices go with it.

The group's first event is the parent and is notified as usual. Events with another key but the same values of the fields picked that come within the window (counted from the parent's opening) become its children: they are stored, show in the list with an In a group badge and on the parent's page under Related events, but send no notice, escalation, renotify or writeback of their own. An event after the window starts a new group. An event whose fields picked are all empty is not grouped (correlate_skipped in the trail).

For cross-source correlation without a policy (events of the same host or service from different sources), see Built-in policies, groups and notification delivery.

#Flap

The Flap action stops an event that opens and closes again and again in a short time (flapping) from sending a notice on every opening.

1. Enter the openings (2–50, default 4) and the window in minutes (1–1440, default 30).
2. Add a Route action to the same policy: the one notice once it settles goes to the route's channels.

When the event opens that often within the window it is marked flapping: it stays one event, gets the tag flapping=true and shows a Flapping badge in the list and on its page. While it flaps no notice, escalation or renotify goes out; auto-resolve still runs. When the window passes without an opening or a closing it stops flapping (Stopped flapping in the timeline); if the event is still open then, the channels get one notice. A flap action also makes the reopen time at least as long as the window, so an event resolved in between does not start a new row.

Try shows how many events of the last 7 days would join a group and how many would flap.

#Examples

Each example starts with New policy; when done, Try, then Save. To test, post an event (with an API token, works from any folder):

curl -s -X POST -H "Authorization: Bearer $SPITFIRE_TOKEN" -H "Content-Type: application/json" \
  -d '{"source":"policy-test","type":"disk.full","severity":"warning","title":"disk 91%","service":"payment","host":"pay-1"}' \
  "https://spitfire.example.com/api/v1/events"

#Mute warnings at night

1. Name: Mute night warnings
2. Severity: One of → Warning, Info
3. Time: Night
4. Action: Suppress (start and end empty)

Check: a warning posted at night shows as Suppressed on the list, the trail says suppress.

#Payment critical → Slack, SMS after 15 minutes without an ack

1. Name: Payment critical
2. Service: payment*
3. Severity: At least → Critical
4. Action: Route → your Slack channel, Replace
5. Action: Escalation → 1 step, 15 minutes, your SMS channel

Check: the event page shows the plan Payment critical, next action in 15 minutes; an ack stops the plan.

#Maintenance window

1. Name: Saturday maintenance
2. Service: api, environment: prod
3. Action: Suppress → start 2026-11-14 02:00, end 2026-11-14 04:00

Check: an event inside the window is Suppressed; outside it the trail says suppress_inactive and the event stays open.

#Dedup ignoring the host

1. Name: Disk full as one event
2. Type: disk.*
3. Action: Dedup → Source, Type, Service, Environment (Host not ticked)
4. Stop here off (later policies apply too)

Check: the same event from pay-1 and pay-2 is one row on the list with count 2.

#Auto-resolve

1. Name: Deploy events close
2. Type: deploy.*
3. Action: Auto-resolve → 60 minutes

Check: an event with no repeat for 60 minutes is Resolved, the timeline says "by policy".

#Incident management with Desktik

The Desktik help desk opens one ticket for each event. Ack, resolve, reopen and severity changes go to the same ticket. A ticket acked or solved in Desktik acks or resolves the Spitfire event too. The Desktik channel is free in every edition.

#Setup

1. In Desktik, turn on Settings → Monitoring events; pick the product, company and requester of the tickets there.
2. In Desktik, create a key starting with dtk_ under Settings → API keys. An events-only key is enough.
3. In Spitfire, choose Integrations → Add channel → Desktik.
4. Enter the Desktik address (https://desk.example.com) and the Desktik API key.
5. Press Test, then save.
6. In Event policies, add the Tracker action to a policy and pick this Desktik channel.

Check: when an event matching the policy opens, the event page shows the Desktik ticket #1234 link.

#The Desktik cloud

When the address is desktik.com or one of its subdomains, event data leaves your organisation. Sending is therefore off by default.

• Nothing goes until Send events to the Desktik cloud is ticked. The channel's delivery history gives the reason.
• With sending on, only the ticked fields go. The default fields are Title, Service and Severity.
• Message and Host often hold internal addresses or customer data. Tick them only if needed.
• With Title unticked, the ticket opens as "Spitfire event ".

A Desktik on your own server gets every field of the event.

#What goes, what comes back

Spitfire sends only the severity; Desktik sets priority and escalation. A flapping or suppressed event opens no new ticket, but an open ticket hears every change of its event.

Desktik does not connect to Spitfire: every 30 seconds Spitfire reads the tickets acked or resolved in Desktik. Desktik needs no Spitfire token. The timeline then shows "Desktik: " and the action is written to the audit log. It is not sent back to Desktik, so there is no loop. When Desktik cannot be reached, the next round reads again; nothing is lost in between.

#The escalation and renotify warning

Desktik escalates and re-notifies by itself. When a policy has a Tracker going to Desktik together with Escalation or Renotify, the policy editor shows a warning; people would be reached twice. Remove one, or keep both on purpose.

#License limits

At the limit no new policy can be added; changing and disabling the existing ones still works.