SLA policies

An SLA policy assigns each entity an SLA class. A class sets the maximum continuous time an entity may stay red before it counts as an SLA breach — a second-level signal that a problem has gone unresolved for too long. SLA is the third policy-driven classification, alongside priority and tags.

SLA classes

An SLA class is a duration threshold, not an uptime percentage. The shipped classes are:

Class

Max continuous red

Notes

platinum

4 hours

The strictest — breaches soonest.

gold

1 day

silver

2 days

The default class, the most lenient.

Important

A more premium class is stricter, not more forgiving — platinum tolerates only four hours of continuous red, while silver tolerates two days. Classes are configured (added, edited, removed) on the Configuration page, under the SLA tab; the thresholds above are the shipped defaults.

How the SLA timer and breach work

Each entity carries an SLA timer — the number of seconds it has been continuously red. The timer starts when the entity flips to red and resets the moment it recovers (or is otherwise no longer red). When the timer exceeds the entity’s class threshold, sla_is_breached becomes true:

  • platinum breaches after 4 hours continuously red;

  • gold after 1 day; silver after 2 days.

An entity that is green, blue, or suppressed is not red, so its timer is 0 and it is never in breach. You can see all of this on the entity’s SLA tab:

An entity's SLA tab showing its class, the continuous-red timer, and the breach state

Assigning an SLA class

  • Manually, per entity — a manual class is flagged and not overridden by policies.

  • By policy — SLA policies use the same three methods as priority and tags (regex, lookup, SPL), per component. A lookup or SPL policy can map foreign values to TrackMe classes — for example a CMDB column of low / moderated / elevated / very_elevated mapped to silver / gold / platinum (wildcards supported).

Note

Unlike priority, SLA policies have no ranking — when several match, the last applied wins. Keep SLA policies narrow and non-overlapping to avoid non-deterministic results.

SLA breach alerts

An SLA breach is a second-level alert. The entity’s first-level stateful alert fires when it goes red; the SLA breach fires separately only once it has stayed red beyond its class threshold — catching the persistent problems that drift past an acceptable time to resolve. You enable it as its own SLA breaches alert type, and breach events are throttled per entity (weekly by default) so a long outage does not spam you.

Creating an SLA breaches alert — a second-level alert on persistent red state

SLA attainment reporting

Separately from the breach threshold, TrackMe reports each entity’s SLA attainment — the percentage of time it spent green over a window. The window defaults to the last 90 days and is configurable (a global setting under Configuration → SLA), which is useful where a workload rule or RBAC restriction prevents searches from running over the full default window. A default SLA overview dashboard ships in the Tenant Home, and the figures are emitted as metrics so you can build your own attainment reports. (This percentage is the historical “how healthy has it been” view; the class threshold is the live “is it red for too long right now” view — two different things.)

Exclusions

Because the timer only runs while an entity is red, anything that takes it out of the red state stops it accruing SLA breach time:

  • Maintenance windows and other suppression hold the entity in blue, so the timer is 0 (and, since recovering resets the timer, the continuous-red count restarts after maintenance).

  • Bank holidays, when enabled, keep the entity out of alert during the excluded periods (see Operations & Administration).

  • Blue (suppressed) entities are treated as not in breach.

Warning

If you remove an SLA class from configuration but entities are still assigned to it, those entities fall back to the default class (silver) — re-assign them explicitly if that is not what you want.

See also