Create a team#
- Open Teams as an organization administrator. Supply a clear name, stable slug, description, and active state.
- Add users with appropriate team memberships. A team's administration role is separate from organization-wide administration.
- Check that people referenced by schedules and policies remain active.
Create a service#
- Open Services and define the service name, slug, environment, description, and business criticality.
- Assign its owning team and an active escalation policy.
- Add a runbook URL and useful metadata. Prefer customer-controlled runbooks for isolated environments.
- Configure severity mappings when source conventions differ from your P1–P5 response model.
- Connect an integration, then verify that an incoming alert appears under the intended service.
Configuration is connected#
Changing a team or service can affect the integrations, routing rules, schedules, and policies that reference it. Inspect active dependencies before deactivation. Do not remove historical database records to make a configuration form accept a change.
Stakeholders, chat and alert sources#
Edit a team or service to add stakeholders, a chat channel and, for services, filtered alert sources and severity mappings. A service's chat channel overrides its team's. Team admins manage stakeholders and chat channels for their own teams.
Useful service context#
- A runbook should explain how to diagnose the monitored condition, what actions are safe, and when to escalate.
- Keep metadata descriptive rather than storing secrets in it.
- Use environment names consistently in monitoring payloads, rules, and service records.
- Business criticality describes importance; normalized alert severity determines response priority.