Service monitors

Proactive support inverts the usual flow: instead of learning about an outage from angry tickets, ServiceOps watches your services and, at the moment one fails, opens the incident and informs the people it affects — before they had to tell you.

What a monitor is

A monitor probes one target on a schedule:

Check type	Verifies
HTTP / HTTPS	The URL answers with the expected status — optionally checking response content
TCP	The host accepts connections on a port (databases, mail, custom services)

You set the interval and the failure threshold — how many consecutive failures mean “this is down”, so one network blip does not page anyone.

What happens on an incident

When the threshold is reached:

1. A ticket is created (if enabled), with the priority you chose, requested by the AI agent — so it is never misattributed to whoever configured the monitor.
2. The impacted audience is emailed (if enabled): the internal group you designated, and/or the customer organization’s contact address. Colleagues are greeted as colleagues, customers as customers — and the notice carries your agent’s full signature.
3. The monitor’s card shows Incident, with the reason (e.g. HTTP 500).

On recovery, the monitor can resolve the ticket automatically and send an all-clear to the same audience.

Create a monitor

1. Open Proactive support and choose New monitor.
2. Name it after the service as users know it — “Payment API”, not a hostname.
3. Choose HTTP or TCP, the target, the interval and failure threshold.
4. Choose the reactions: create a ticket (and its priority), notify the impacted group and/or client, resolve and notify on recovery.
5. Save. The first check runs on the next scheduling tick.

Result: the monitor card goes Operational — flip the target off, and within your threshold × interval you will see the incident ticket, the notification email, and the reason on the card.

Organization-wide settings

Organization → Settings → Monitoring carries the defaults monitors inherit — so individual monitors only override what is special about them.

Tip

Point monitors at what users experience — the login page, the public API endpoint — rather than only at internal health checks. “The health check is green but nobody can log in” is exactly the outage this feature exists to catch.