A service is a product, app or piece of infrastructure that your team manages. It could be something that your customers rely on directly such as a shopping cart or API service, or something those things rely on such as a database or the individual hosts on which they run.

There's really no right answer to how many services to define or where the boundaries should be. A very small team responsible for a single product might have only a single service that represents the health of some system as a whole. Larger teams might create additional services that represent distinct products or systems, or even services that mirror the organizational structure of the team that manages them.

For example, if one application depends on another application, it might be useful to create a service for each–that allows identifying the healthiness of a system based on the health of it's component systems.

Each service specifies an escalation policy that defines schedules to route alerts, and optionally, one or more integrations.