Rootly Services
Overview
The Rootly service catalog provides a centralized registry of all services in your infrastructure. Each service has ownership, tier classification, dependencies, and is linked to incidents and alerts. This enables rapid identification of affected components during incidents and accurate impact assessment.
Key Concepts
Service Tiers
Services are classified by business criticality:
- Tier 1 / Critical -- Revenue-generating, customer-facing services (e.g., payment processing, API gateway)
- Tier 2 / High -- Important internal services (e.g., CI/CD, monitoring)
- Tier 3 / Medium -- Supporting services (e.g., internal dashboards, dev tools)
- Tier 4 / Low -- Non-critical services (e.g., documentation sites)
Service Ownership
Each service has:
- Owner Team -- Team responsible for the service
- Slack Channel -- Communication channel for the service
- Escalation Policy -- How alerts are routed
- Runbooks -- Links to operational documentation
Service Dependencies
Rootly tracks upstream and downstream dependencies:
- Upstream -- Services this service depends on
- Downstream -- Services that depend on this service
- Impact Analysis -- When a service is affected, Rootly identifies dependent services at risk
API Patterns
List Services
rootly_list_services
Parameters:
team-- Filter by owning teamtier-- Filter by service tierenvironment-- Filter by environment
Example response:
{
"data": [
{
"id": "svc-001",
"type": "services",
"attributes": {
"name": "payment-service",
"slug": "payment-service",
"description": "Handles payment processing via Stripe",
"tier": "tier_1",
"owner": { "name": "Platform Team" },
"slack_channel": "#payment-service",
"status": "operational",
"incidents_count": 2,
"dependencies_count": 3
}
}
]
}
Get Service Details
rootly_get_service
Parameters:
service_id-- The service ID
Create Service
rootly_create_service
Parameters:
name-- Service name (required)description-- Service descriptiontier-- Service tierteam_id-- Owning team IDslack_channel-- Associated Slack channel
Update Service
rootly_update_service
Parameters:
service_id-- The service IDname-- Updated namedescription-- Updated descriptiontier-- Updated tierteam_id-- Updated owning team
Common Workflows
Service Health Check
- Call
rootly_list_servicesto get all services - Cross-reference with active incidents via
rootly_list_incidents - Identify services with open incidents
- Check dependency chains for cascading impact
- Report overall service health summary
Service Dependency Analysis
- Get service details with
rootly_get_service - Review upstream and downstream dependencies
- Identify single points of failure
- Assess blast radius for potential outages
- Recommend redundancy improvements
Incident Impact Assessment
- Get incident details to identify affected services
- For each affected service, look up downstream dependencies
- Assess total impact scope (direct + transitive dependencies)
- Determine affected teams and escalation paths
- Communicate impact to relevant stakeholders
Error Handling
Service Not Found
Cause: Invalid service ID or service deleted Solution: List services to verify the correct ID
Duplicate Service Name
Cause: Service with this name already exists Solution: Use a unique name or update the existing service
Invalid Tier
Cause: Tier value doesn't match configured tiers Solution: Use valid tier values (tier_1, tier_2, tier_3, tier_4)
Best Practices
- Keep the service catalog up to date as infrastructure evolves
- Assign clear ownership for every service
- Map dependencies accurately for blast radius analysis
- Use consistent naming conventions for services
- Link services to monitoring dashboards and runbooks
- Review service tiers quarterly as business priorities change
- Tag services with environments for accurate incident scoping
- Track incident frequency per service to identify reliability gaps
Related Skills
- api-patterns - Pagination and error handling
- incidents - Incidents affecting services
- alerts - Alert routing by service
- workflows - Service-triggered workflows