Monitors Overview

A monitor is one thing Pingniner watches. There are seven types, and while they check very different things, they share the same structure: a check runs on a schedule, its result is compared against your triggers, and a trigger that fires often enough raises an incident and notifies people.

The seven types

Type	Watches	Checked by
Sites	A URL over HTTP(S) — uptime, response time, content, SSL and domain expiry	Pingniner, from a location you pick
Servers	A whole host — CPU, memory, disk, network, services, Docker	The agent, every minute
Workstations	Laptops and desktops — inventory, storage, apps	The agent, every hour
Pings	Whether a host answers ICMP ping	Pingniner, from a location you pick
Ports	Whether a TCP port accepts connections	Pingniner, from a location you pick
Heartbeats	Whether a scheduled job checked in on time	Your job, calling Pingniner
Blacklists	Whether an IP address appears on DNSBLs	Pingniner

Note the direction of travel differs. Sites, pings, ports and blacklists are pulled — Pingniner reaches out to them. Servers and workstations are pushed — the agent reports in. Heartbeats are pushed too, by your own code.

That matters for firewalls: only the pulled types need to be reachable from the internet.

INFO

All seven types count toward your plan's monitor limit, servers and workstations included. See Plans & Limits.

Concepts every monitor shares

Status

Every monitor is in exactly one of five states:

Status	Meaning
Unknown	No check has completed yet — normal for a monitor you just created
Up	Everything passing
Degraded	A trigger with Degraded impact is firing
Down	A trigger with Down impact is firing
Maintenance	A maintenance period is currently in effect

Triggers

A trigger is a condition — "response time over 4000 ms", "disk over 90%", "no data at all". Each carries an impact that determines the resulting status, an occurrences count that controls how many consecutive failures are needed, and a list of contacts to notify.

Some types let you create your own triggers (servers, workstations); the rest ship a fixed catalogue you can enable, disable and tune. See Triggers & Incidents.

Incidents

When a trigger has failed for its full occurrences count, an incident opens and notifications go out. When the condition clears, the incident closes and a recovery notification is sent. Every monitor has an Alerts tab listing its incidents.

Frequency and locations

Pulled monitors (sites, pings, ports, blacklists) have a Monitoring frequency and a Monitoring Location. Which frequencies you can choose depends on your plan — see Plans & Limits. Sites can add up to five additional locations on paid plans.

Groups, tags and notes

Every monitor can belong to a group, carry free-form tags, and hold notes. All three are for your own organisation and filtering — see Groups & Tags.

Maintenance periods

Sites, servers, pings, ports and heartbeats support scheduled maintenance windows, during which checks still run but triggers and notifications are suppressed. Workstations and blacklists do not. See Maintenance Periods.

Retention

How long check history is kept is set by your plan and applied per monitor. Incident records are kept regardless. See Plans & Limits.

Choosing the right type

• Is my website up? → Site
• Is my API returning the right thing? → Site with Expected status code and a Contains trigger
• Is my server healthy? → Server
• Is this host reachable at all? → Ping
• Is my database / SMTP / SSH accepting connections? → Port
• Did my nightly backup actually run? → Heartbeat
• Is my mail server's IP blacklisted? → Blacklist
• What laptops does my team have, and are their disks full? → Workstation