Monitor Types

Every kind of check you can create, grouped the way the type picker groups them, and the settings all monitors share.

To create a monitor, click New on the Monitors page and open Monitor type. The picker has a search box, so typing ssl or port finds the type quickly. Entries marked SOON cannot be selected yet.

Website & availability

Security & certificates

Application & APIs

Infrastructure & services

Database engines

Database monitor is one entry for every engine. You pick the engine in the form, or paste a connection string and Zharp reads the engine from its scheme.

Set Connection to Public to connect directly over the internet, or Private to check a database through a Zharp agent installed next to it.

Custom

Custom monitor is for anything the other types do not cover. Zharp either polls an endpoint you give it (pull) or waits for you to send it data (push), and you write trigger rules — with a condition builder or a script — that decide when to raise an alert or mark the monitor down. See Custom Monitors.

Settings every monitor has

The type-specific fields sit in the first section of the form. The settings below are common to every type. Most are under Advanced settings, which is collapsed until you click it.

A Cron job monitor does not use Check frequency: it follows the Expected schedule in its own Cron settings. A Custom monitor in push mode does not poll, so the field is disabled.

Confirmation and recovery periods

A monitor goes down when more than half of its regions fail. With a Confirmation period, that has to keep being true for the whole period first: while it runs the monitor keeps its current status, no incident opens and nobody is alerted, and Zharp checks again as the period ends rather than waiting for the next scheduled check. A check that passes in between starts the period over.

The Recovery period works the same way in the other direction: a down monitor only goes back up, and its incident only closes, once checks have passed for that long.

Timeouts

Each check gives up after its timeout and counts as failed. Websites, keyword and API monitors use Request timeout (Max response time for API monitors); a Ping monitor uses the Timeout in ICMP settings, a Port monitor the Connection timeout in Connection settings, and the mail monitors the Timeout in their own Connection settings. Timeouts are between 1 and 60 seconds.

Ping and port settings

A Ping monitor's ICMP settings and a Port monitor's Connection settings apply in every region:

Testing before you save

A test run — Run Script for a workflow, or the API's POST /api/v1/monitors/test-connection — builds its check from the form exactly as the scheduled check will, so every setting above counts — a user journey's test run included, which uses its browser settings. A test crawl of a broken-links monitor is limited to one level and 30 seconds, and a security scan to 30 seconds, so the answer comes back in time.

Notify the on-duty member

The person on shift in your primary on-call schedule is alerted, once. With no schedule, or nobody on shift, the monitor's “is DOWN” alert is all that goes out. Under How should we notify the on-duty member? choose any of:

• E-mail — ticked by default.
• Push notification
• Slack alert — posts to a Slack connection, which you pick under Send Slack alerts through.

Call and SMS are shown but cannot be selected yet. Under If the on-duty member doesn't acknowledge the incident:

Escalation policy

Pick an existing policy from the list, or choose + Create new policy to build one in place; it is saved when you create the monitor. See Escalation & On-call.

Maintenance

The Maintenance section of the form sets a recurring quiet period for this monitor alone: pick the start and end time under Maintenance window between, the timezone they are in, and the days it applies to (Monday to Friday by default). The window starts at that time on each selected day; if the end time is earlier than the start, it runs past midnight and ends the next morning. Leave both times the same to have no window. Saving the monitor replaces its window, and the window keeps following local time in its timezone when clocks change.

For a one-off window, or one that covers several monitors, schedule it from Maintenance in the sidebar and add the monitors under Affected services — see Core Concepts. Those windows are kept when you edit a monitor. While any window covering the monitor is in progress, the monitor shows Maintenance and no incidents or alerts are raised.

Metadata

Under Metadata you can attach key/value pairs to the monitor. They are copied onto its incidents, used by metadata rules in escalation policies, and can be inserted into alert messages as placeholders such as {server_region}. Editing the monitor keeps them.

What an edit keeps

Saving the form changes only the settings it shows. Tags, a muted alert, the time stats were reset, settings written through the API and the state the checks keep for themselves stay as they were. A field you clear in the form is removed from the monitor.

Editing a paused monitor

Saving the form keeps the monitor as it was: a paused monitor stays paused and a running one keeps running. Use Pause or Resume on the monitor page to change that.

From the monitor page

The … menu at the top of a monitor's page has these actions as well as edit, pause and delete:

Deeper guides