Triggers & Incidents

Overview

A trigger is a rule attached to a monitor. Every time a check completes, Pingniner evaluates the monitor's active triggers against the result. When a trigger has failed enough times in a row, an incident opens and the people you nominated are notified.

Understanding four settings — occurrences, impact, contacts and repeats — is most of what you need to make alerting useful rather than noisy.

Occurrences

Occurrences is how many consecutive failing checks are required before an incident opens. It exists because networks are unreliable and a single failed check usually means nothing.

With the default of 3 occurrences on a site checked every minute, a genuine outage is reported after roughly three minutes, and a one-off blip is silently ignored.

TIP

Getting alerts for problems that resolve themselves before you finish reading the email? Raise occurrences, don't disable the trigger. Going from 3 to 5 removes most transient noise without hiding real outages.

Occurrences can be set from 1 to 50. Some triggers ignore it by design — Blacklisted uses 1, and heartbeat Grace Time Exceeded has no occurrences field at all, because in both cases a single observation is already conclusive.

Impact

Impact is what the trigger does to the monitor's status when it fires:

Impact	Resulting status	Use for
None	Status unchanged	Informational alerts you want notifications for but which shouldn't mark anything as broken
Degraded	Degraded	Working but not well — slow responses, a filling disk, a stopped non-critical service
Down	Down	Not working — unreachable, offline, no data

This value matters beyond the monitor's own page: status pages and uptime reports both derive their figures from it. Downtime in your monthly report is time spent in a Down state.

On servers and workstations you choose the impact yourself. On the other types it is fixed per trigger — Offline is always Down, Response time is always Degraded.

Contacts

Contacts is the list of people notified when the trigger fires. Anyone in your account can be selected, including contacts who cannot sign in and exist purely to receive alerts.

Each person receives the alert on whichever notification channels they have configured on their own profile. There is no per-trigger channel selection — the trigger decides who, the recipient decides how.

WARNING

A trigger with no contacts still opens incidents and still affects the monitor's status — it just tells nobody. If alerts have gone quiet, check the contacts list first.

Repeating notifications

By default you are notified once when an incident opens and once when it closes. If you want reminders while it is still open, set Repeating notifications to one of: every 5, 15 or 30 minutes, or every 1, 2, 6, 12 or 24 hours.

Reserve short intervals for things that genuinely need someone woken up. A 5-minute repeat on a non-critical monitor is the fastest way to train a team to ignore alerts.

Active

Turning a trigger off stops it being evaluated entirely. It does not delete the trigger or its history, so this is the right way to temporarily silence something you plan to re-enable.

For a planned window with a known end, use a maintenance period instead — it suppresses everything on the monitor and turns itself off again.

Comparison operators

Server and workstation triggers let you choose how the value is compared:

Operator	Meaning
==	Equal to
!=	Not equal to
>=	Greater than or equal to
<=	Less than or equal to
>	Greater than
<	Less than
Contains	The reported text contains this value
Does not contain	The reported text does not contain this value

State-based triggers — No Data, Service not running, Docker Not Running — have no comparison, because there is nothing to compare.

Median response time Paid plans

Every trigger described so far compares a measurement against a number you chose. That works when you know what "too slow" means in milliseconds, and fails when you don't: an API that normally answers in 40 ms and starts taking 900 ms is badly degraded, and nowhere near any threshold a sensible person would have set.

The Median response time trigger compares a monitor against itself instead.

How it works

1. Every night, Pingniner computes each monitor's 7-day median response time — its normal.
2. Every five minutes, it computes the median of the last 15 minutes.
3. If the recent figure is more than your deviation threshold above the baseline, an alert fires.

A threshold of 100% means the median must double. That is the default.

The median rather than the average, deliberately: response times are long-tailed, and one 30-second timeout among two hundred 40 ms checks moves an average enough to look like a regression while moving the median not at all.

What it will not do

Several guards exist to keep this from becoming noise:

• It does not change your monitor's status. A slow monitor stays Up, so it is never published as impaired on a status page and slow periods are never counted as downtime in your uptime reports. This trigger notifies and nothing more.
• It ignores small absolute numbers. 8 ms becoming 30 ms is a 275% increase and imperceptible. Nothing under 250 ms fires, whatever the percentage says.
• It does not fire during an outage or maintenance. A monitor that is Down or in a maintenance period is skipped — Offline already covers that, and the handful of checks around a recovery make a meaningless median.
• It waits for enough data. A baseline needs a week of history behind it, so a newly created monitor stays quiet until it has one.
• It will not flap. Once open, the alert resolves only when the deviation falls well below the threshold, rather than the moment it dips under.

Availability

Available on paid plans. On the free plan the trigger appears but cannot be enabled — the 7-day baseline it depends on needs more history than the free plan's 24-hour retention keeps. See Plans & Limits.

Tuning it

• Start at the default 100% and lower it only if you find real problems arriving too late.
• 50% suits an endpoint whose response time is normally very stable.
• 200% or more suits anything naturally variable — a search endpoint, or a page whose cost depends on the query.

Available on Sites, Pings and Ports.

The incident lifecycle

1. A check fails in a way that matches an active trigger.
2. The consecutive-failure count increases. Nothing is sent yet.
3. The count reaches the trigger's occurrences value. An incident opens, the monitor's status changes according to the trigger's impact, and the trigger's contacts are notified.
4. If repeating notifications are on, reminders are sent at that interval while the incident stays open.
5. A passing check closes the incident and sends a recovery notification.

Incidents are listed under each monitor's Alerts tab, showing the trigger, start time, end time and last notification.

INFO

Incident records are kept permanently, unlike check history, which is pruned according to your plan's retention. This is why uptime reports can cover a full month even on plans with short history retention.

Overlapping triggers

A monitor can have several triggers firing at once — a site can be both slow and returning the wrong status code. Each opens its own incident.

For uptime calculations, overlapping downtime is counted once. An hour of downtime that happened to trip two triggers is reported as one hour, not two.

Resetting triggers

Servers and workstations have a Reset triggers action, both in the header of the Triggers page and as a bulk action on the list. It discards your customisations and restores the defaults for that monitor.

It cannot be undone, so treat it as a way out of a tangle rather than routine maintenance.