Every monitor type has a New form under its own sidebar entry in Monitors, or one click away in the + create menu. The forms share a common skeleton and differ only in the middle.
Monitor types and what each one proves are covered in Monitor types; the equivalent commands are in Monitors (CLI) and Protocol monitors (CLI). This page is about the forms.
What every form asks for#
| Field | Notes |
|---|---|
| Monitor Name | Required, and cannot be blank. |
| Description | Optional. |
| Monitoring frequency | A cron expression, chosen from presets (every minute through monthly) or written by hand. Leave it empty to disable scheduled checks, so the monitor only runs when you trigger it. |
| Alert on Failure | Sends notifications when the check fails, together with a picker for which alert channels it notifies. Turning the switch on without ticking a channel gives you an alert with nowhere to go. |
| Execution Regions | Where the check runs from: US East (Virginia), US West (California), EU West (Amsterdam), Southeast Asia (Singapore). |
| Retry Count | None, 1, 2, 3 or 5 retries before the check is called failed. |
| Retry Interval | 1, 5, 10 or 30 minutes, or 1 hour between retries. |
| Timeout | Between 1 000 ms and 60 000 ms. |
Execution Regions sit in the main form. Retries, timeout, the alert-channel picker and the project/environment binding are under Advanced Settings, which starts collapsed, so open it on a first monitor: the channel picker lives in there.
Project and environment#
Any monitor can be bound to a Project and an Environment, or left as No project. An environment supplies the {{KEY}} tokens that the monitor's own string fields resolve at run time, such as the URL on a URL monitor or the host and payload on a TCP monitor. The form tells you which of its fields interpolate.
See Projects (CLI) and Collections & Environments.
Per-type fields#
URL monitor#
Takes a URL, which must start with http:// or https://.
Add assertions to make the check mean something beyond "the server answered". An assertion picks an operator (Equals, Not Equals, Less Than, Greater Than) and a value. Common status codes are offered as presets: 200, 201, 204, 301, 302, 400, 401, 403, 404, 500, 502, 503.
SSL monitor#
Takes a Host, plus Warn me before expiry (days). That sets how far ahead of certificate expiry the monitor starts alerting, so the warning arrives while there is still time to renew.
TCP monitor#
Takes a host and port, an optional Payload (hex) to send on connect, and an optional Expected banner to match against what comes back.
UDP monitor#
Takes a host and port and an optional Payload (hex). UDP has no connection to succeed at, so a switch, Only pass if a reply is received, decides whether silence counts as healthy.
DB monitor#
Takes a Protocol (PostgreSQL, MySQL or Redis), connection details, and Connect over TLS.
Heartbeat#
Heartbeats are inverted: your job pings ObserveOne, and the monitor fails when the ping does not arrive. The form takes a Heartbeat Name, a Description, an Expected Period (how often you expect a ping, from every 30 seconds up to every 7 days, or a custom value), a Grace Period (seconds) of at least 10, and Alert on Failure. The grace period is how long past the expected time ObserveOne waits before calling the ping missed, so it should cover your job's normal jitter and no more.
Full details in Heartbeats.
Two notices that catch people out#
Public reachability. TCP, UDP and DB checks connect directly from ObserveOne's cloud, so the target has to accept inbound connections from outside your network. The forms warn about this but do not block you. A check against a target only reachable inside your VPC will simply fail. Monitoring private infrastructure covers the ways round it.
Schedule clamping. Each plan has a minimum interval between checks. If a monitor's saved schedule is faster than your plan allows, the form shows that plan minimum instead of what was saved, with a notice saying so. The clamp applies when you next save, and is not backfilled, so a monitor you never edit keeps its old interval and one you edit for an unrelated reason picks up the slower schedule. Read the notice before saving.
Next steps#
- Notification channels so a failing monitor has somewhere to alert.
- Monitor types for what each type actually proves.
- Monitors (CLI) for the same monitors from a terminal.