Rootly Services — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Rootly Services (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The Rootly service catalog provides a centralized registry of all services in your infrastructure. Each service has ownership, dependencies, and is linked to incidents and alerts. This enables rapid identification of affected components during incidents and accurate impact assessment.
A Rootly service is a technical component with an owning team. It is not a commercial service, not a service ticket, and not a device record.
scope, and rates live in the contract; use halopsa-contracts or autotask-contracts.
helpdesk or PSA; use freshdesk-ticketing, halopsa-tickets, or connectwise-psa-tickets.
integrations and escalation policies. A Rootly service can link to a PagerDuty service via pagerduty_id, but the two catalogs are separate; use pagerduty-services for PagerDuty's own model.
records are halopsa-assets or the RMM's device skills.
The Rootly service object has no built-in "tier" or "criticality" property. If your org needs a Tier 1 / Tier 2 / Tier 3 classification, model it with a custom field or with naming/labeling conventions -- do not expect a tier filter or attribute on the service record itself.
Each service can carry:
A service can carry identifiers linking it to external systems, all stored directly on the service record:
pagerduty_id, opsgenie_id -- Paging tool service IDscortex_id, backstage_id -- Service catalog / internal developer portal IDsservice_now_ci_sys_id -- ServiceNow CI recordgithub_repository_name / github_repository_branch -- Source repogitlab_repository_name / gitlab_repository_branch -- Source repoRootly tracks dependencies as a flat list on the service record:
There is no separate upstream/downstream distinction in the API -- service_ids on a given service is the set of services Rootly considers dependent on it. Build a fuller dependency graph by reading service_ids across multiple services.
list_servicesParameters:
filter[search] -- Free-text searchfilter[name] -- Filter by exact namefilter[slug] -- Filter by slugfilter[external_id], filter[backstage_id], filter[cortex_id], filter[opslevel_id] -- Filter by third-party IDpage[number] / page[size] -- PaginationThere is no team, tier, or environment filter parameter on this endpoint -- filter client-side on owner_group_ids / environment_ids after fetching, or filter incidents by service_ids instead (see incidents).
Example response:
{
"data": [
{
"id": "svc-001",
"type": "services",
"attributes": {
"name": "payment-service",
"slug": "payment-service",
"description": "Handles payment processing via Stripe",
"owner_group_ids": ["team-platform"],
"slack_channels": [{ "id": "C123", "name": "#payment-service" }],
"environment_ids": ["env-prod"],
"service_ids": ["svc-002", "svc-003"]
}
}
]
}get_serviceParameters:
create_serviceParameters:
name -- Service name (required)description -- Service descriptionowner_group_ids -- Owning team ID(s)owner_user_ids -- Owning user ID(s)environment_ids -- Associated environmentsservice_ids -- Dependent servicesupdate_serviceParameters:
name -- Updated namedescription -- Updated descriptionowner_group_ids -- Updated owning team(s)service_ids -- Updated dependenciesget_service_incidents_chart
get_service_uptime_chartParameters:
Returns chart data for incident frequency and uptime for the service, useful for reliability reporting.
list_services to get all serviceslist_incidents filtered by filter[service_ids]service_ids on each affected service for cascading impactget_service_incidents_chart per serviceget_serviceservice_ids to see which services are recorded as dependentservice_ids to find what this service itself depends onservice_ids on the incident)service_ids (dependents) via get_serviceowner_group_ids and escalation pathsCause: Invalid service ID or service deleted Solution: List services to verify the correct ID
Cause: Service with this name already exists Solution: Use a unique name or update the existing service
owner_group_ids and/or owner_user_ids) for every serviceservice_ids accurate on both sides of a dependency for blast-radius analysisenvironment_ids for accurate incident scopingget_service_incidents_chart periodically to identify reliability gaps~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.