Rootly Workflows — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Rootly Workflows (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.
Rootly workflows automate repetitive incident response tasks. Each workflow has a trigger type (what kind of event starts it, e.g. incident, post_mortem, action_item, alert), a set of specific trigger events within that type (e.g. incident_created, status_updated), matching filters (which severities/services/environments/teams it applies to), and one or more workflow tasks -- each task carries a specific task_type such as create_slack_channel, page_rootly_on_call_responders, or send_email.
"Workflow" means automation inside Rootly, fired by incident/alert/action-item/postmortem events. Several neighbouring things share the word.
agents/*.md and slashcommands under commands/*.md are plugin authoring concerns, not Rootly resources. Nothing in this skill configures Claude.
notification rules inside a PSA are connectwise-psa-tickets, halopsa-tickets, or autotask-tickets.
workflows are a separate product surface; use pagerduty-incidents and pagerduty-alerts.
datto-rmm-jobs, not a Rootly action.
read from list_workflow_runs, not this skill's conceptual reference.
A workflow record has:
name, description, slugenabled -- Whether the workflow is currently active (there is no separate enable/disable tool -- toggle this field with update_workflow)trigger_params -- The trigger type and specific events (see below)environment_ids, severity_ids, incident_type_ids, service_ids, functionality_ids, group_ids (teams), cause_ids, sub_status_idsworkflow_group_id -- Optional grouping for organizationrepeat_every_duration, continuously_repeat, repeat_condition_number_of_repeats -- Repeat/retry behaviortrigger_params is one of six shapes, selected by trigger_type:
trigger_type | Fires on |
|---|---|
incident | Incident lifecycle and field-change events |
post_mortem | Retrospective (postmortem) lifecycle events |
action_item | Action item lifecycle events |
alert | Alert events |
pulse | Pulse (recurring check) events |
simple | A minimal manual/generic trigger |
Each trigger type has its own triggers array of specific event names. Confirmed values include:
incident_created, incident_started, incident_in_triage, incident_updated, title_updated, summary_updated, status_updated, severity_updated, services_added/removed/updated, environments_added/removed/updated, incident_types_added/removed/updated, functionalities_added/removed/updated, teams_added/removed/updated, role_assignments_added/updated/removed, timeline_updated, slack_commandpost_mortem_created, post_mortem_updated, status_updated, slack_commandaction_item_created, action_item_updated, assigned_user_updated, status_updated, priority_updated, due_date_updated, slack_commandRootly does not use a severity_is / severity_gte style condition object. Instead:
severity_ids, service_ids, environment_ids, group_ids, etc. with the specific records the workflow should apply totrigger_params, per-field condition operators (e.g. incident_condition_status, incident_condition_kind) support IS, ANY, CONTAINS, CONTAINS_ALL, CONTAINS_NONE, NONE, SET, UNSETincident_condition: ALL / ANY / NONE) controls how multiple conditions combineA workflow's actions are separate workflow_task records (see Common Query Patterns), each with a task_type. Confirmed task_type values include:
task_type | Description |
|---|---|
create_slack_channel | Create a dedicated incident Slack channel |
invite_to_slack_channel | Add responders to a Slack channel |
send_slack_message | Post a message to a channel |
page_rootly_on_call_responders | Page via Rootly's own on-call/schedules |
page_pagerduty_on_call_responders / page_opsgenie_on_call_responders | Page via a connected paging tool |
create_jira_issue | Create a tracking issue in Jira |
send_email | Send email notification |
create_zoom_meeting | Start a video bridge for the incident |
http_client | Call a custom HTTP endpoint (Rootly's generic webhook action) |
add_role | Assign an incident role |
update_status | Change the incident's status |
update_incident | Modify incident fields |
create_incident_postmortem / update_incident_postmortem | Create or update the incident's retrospective (see postmortems) |
This is a representative subset -- Rootly's OpenAPI spec defines well over 100 task types (per-vendor paging/ticketing/wiki integrations, etc.). Use list_workflow_tasks on an existing workflow to see exactly which task types are in use, rather than assuming a name.
list_workflowsParameters:
filter[search], filter[name], filter[slug]page[number] / page[size]Example response:
{
"data": [
{
"id": "wf-001",
"type": "workflows",
"attributes": {
"name": "SEV0 Auto-Response",
"description": "Create war room and page on-call for critical incidents",
"enabled": true,
"severity_ids": ["sev-0"],
"trigger_params": {
"trigger_type": "incident",
"triggers": ["incident_created"]
}
}
}
]
}get_workflowParameters:
create_workflowParameters:
name -- Workflow name (required)description -- What the workflow doestrigger_params -- Trigger type and event listseverity_ids / service_ids / environment_ids / etc. -- Matching filtersenabled -- Whether to enable immediatelyupdate_workflowParameters:
name -- Updated nameenabled -- Set true/false to enable or disable -- there is no separate enable/disable tooltrigger_params -- Updated triggerlist_workflow_tasks
create_workflow_taskParameters:
task_params -- An object whose task_type selects the action (see table above) plus that action's specific fieldslist_workflow_runsParameters:
Returns the history of when this workflow fired and what it did -- this is where you check whether a workflow is actually running.
list_workflows to get all workflowslist_workflow_tasks to see its actions and check severity_ids/service_ids for scopeservice_ids) without automated responseenabled: false workflows that should be activecreate_workflow, trigger_params.trigger_type = "incident", trigger_params.triggers = ["incident_created"]severity_ids to the SEV0 severity IDcreate_workflow_task: task_type: "create_slack_channel", task_type: "page_rootly_on_call_responders", task_type: "create_zoom_meeting"enabled: true via update_workflow (or at creation)list_workflowslist_workflow_runs to see how often it actually firesseverity_ids/service_ids/condition operators to reduce false triggersCause: Invalid workflow ID or workflow deleted Solution: List workflows to verify the correct ID
Cause: trigger_params.trigger_type doesn't match one of incident, post_mortem, action_item, alert, pulse, simple Solution: Use one of the six documented trigger types, with a triggers array of event names valid for that type
Cause: External integration (Slack, Jira, PagerDuty) returned an error for a workflow_task Solution: Check integration credentials and permissions; review list_workflow_runs for the failure detail
enabled: trueseverity_ids/service_ids/environment_ids to avoid workflows firing on every incidentlist_workflow_runs regularly to detect misconfiguration (never fires, or fires too often)enabled: false rather than deleting a workflow you might need againdescriptionincident_updated trigger can itself update the incident and re-fire~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.