Binding monitors to services

A monitor can be soft-bound to one entry in the service catalog through service_id. Binding is optional (most monitors never need it), and a monitor can only be bound to a service in its own organization.

up0 monitors

up0 monitors list

Lists every monitor in the active organization along with the service it is bound to, or unbound:

             Monitors (6 total)
┏━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━┳━━━━━━━━━┓
┃ name          ┃ type  ┃ status ┃ service ┃
┡━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━╇━━━━━━━━━┩
│ Production API│ http  │ up     │ unbound │
└───────────────┴───────┴────────┴─────────┘

up0 monitors bind "Production API" --service api-gateway
up0 monitors unbind "Production API"

bind and unbind take a monitor by id or by its exact name, and resolve --service by name within your organization. Both drive PATCH /api/v1/me/monitors/{id} with service_id set or cleared, so they work equally with a monitor created any other way.

The service has to already exist in your catalog. bind does not create one, and binding to a name that isn't there fails clearly:

$ up0 monitors bind "Production API" --service does-not-exist
Error: HTTP 404: no service named 'does-not-exist' found in this organization

See Services for how the catalog gets populated.

What binding changes

Binding is read in two places today:

• The service's Objectives section. An Objective can target a service directly, or target a monitor bound to that service. Binding is what makes the second case resolvable, and the service page merges both when it lists which objectives apply.
• Issue-to-incident correlation. Once a monitor is bound to a service, an incident from that monitor and an issue on that same service can be correlated. An unbound monitor's incidents are not correlated to anything.

Binding does not change how the monitor itself is checked, and it does not appear on the monitor in any other way. There is no monitor detail page to show it on yet (see Monitors).