Rootly

Connect Rootly so agents can triage open incidents, review alerts, and file the follow-up action items an incident leaves behind

Connect Rootly and CloudThinker agents can list open and recent incidents, check which alerts became incidents, and track the action items (follow-up tasks attached to an incident) still owed after a response. The connection uses a Rootly API key. Agents read freely and can make one kind of change: an incident action item.

Prerequisites

• Access to Organization Settings in Rootly, where API keys are created.
• Edit permission on connections in your CloudThinker workspace.

Setup

1. Create an API key in Rootly

   In Rootly, open the organization dropdown in the top-left corner and go to Organization Settings → API Keys. Click Generate New API Key, name it cloudthinker, and pick Global scope so the key can read every team’s incidents.

   Copy the key right away. Rootly shows it only once, so a lost key means generating a new one.

2. Add the connection in CloudThinker

   In the sidebar, click More → Workspace settings → Connections. On the Builtin Connections tab, search for Rootly and click Connect.

   Paste the key into API Key and click Connect. CloudThinker tests the key against the Rootly API.

   Success state: the connection shows Connected, and the test message names the key’s user, for example Rootly connection verified (Jane Doe).

Connection details

Field	Description	Example
API Key	The Rootly API key from Organization Settings → API Keys	<your-api-key>

There’s no endpoint or region to enter. CloudThinker calls https://api.rootly.com/v1 directly.

Required permissions

Rootly scopes a key when you create it and has no per-endpoint permission list, so the scope is your only control.

Key scope	What agents see
Global	Every team’s incidents, alerts, and action items. Recommended.
Team	One team’s data. Use it when agents should see nothing else.
Personal	Only what that user can see.

A Team or Personal key still connects. List reads then return fewer rows with no error, which looks like a quiet account. Reading one specific item outside the key’s scope returns 403. If counts seem low, check the key’s scope first.

Agent capabilities

Capability	What agents can do	Checked by Approvals
Discovery	Read the key’s user and your account’s severity, team, service, environment, and incident type names	No
Incident triage	List open and recent incidents with status, severity, kind, impacted services, responding teams, timestamps, and a link	No
Alert review	List alerts with status, source, urgency, owning service, and whether each one became an incident	No
Follow-up tracking	List an incident’s action items, who owns each one, and which are still owed	No
Action item writes	Create, update, or delete one incident action item at a time	Yes

Defaults and limits

Read	Default window	Default rows	Max rows
Incidents	Last 168 hours (7 days), by when the record was created	20	100
Alerts	Last 24 hours	25	100
Action items (account-wide)	Last 720 hours (30 days)	25	100
Discovery	Not time-bound	15 per section	100

Every answer reports how many rows it read and how many Rootly matched. If an answer says truncated, ask for a shorter window or more rows before treating the count as the total.

Incidents of kind test or example are rehearsals. They’re included unless you ask the agent to exclude them.

Verify the connection

Run Rootly discovery and summarize the key's user, the severity names this account uses, and how many teams and services you can read

A working connection lists your own severity names, such as SEV1 and SEV2. An error that mentions 403 means the key is too narrow.

Example prompts

List the Rootly incidents still open right now, with severity and impacted services
Which Rootly alerts from the last 24 hours never became an incident?
What action items are still owed on the most recent SEV1 incident, and who owns each one?

Write access

Agents can’t declare, update, resolve, or delete a Rootly incident. Declaring one through the API runs your account’s real workflows: it can open a Slack channel, notify subscribers, and page on-call. Deleting it afterwards doesn’t undo any of that, so incident changes stay in Rootly.

The one change agents can make is to an incident action item: create one, update one, or delete one. An action item attaches to an existing incident and doesn’t change its state. Your Rootly account can still have a workflow that fires on action items, and CloudThinker can’t see which workflows you’ve enabled.

How a write runs:

1. The agent finds the incident or action item ID with a read first. It never guesses an ID.
2. The change goes through your Approvals rules and mode.
3. The agent makes one change per approval, then reads the item back and reports whether the change is there. Rootly returns 200 even for an update that changed nothing, so the read-back is the proof.

Allow writes is on by default. To keep the connection read-only, go to More → Workspace settings → Connections, select Rootly, and turn off Allow writes. Agents then refuse every change.

Troubleshooting

Rootly rejected the API key

Rootly answered 401. The key was copied incompletely or revoked. Generate a new key in Organization Settings → API Keys, then open the Rootly connection in CloudThinker and replace the saved value.

Rootly accepted the key but refused the request

Rootly answered 403. The key is probably Team-scoped or Personal, or the role on your Global key was narrowed. Generate a Global key, leave its role in place, and update the connection.

A filtered question returns nothing

Rootly returns an empty list, not an error, for a severity, team, or service name your account doesn’t use. Ask the agent to run discovery first, then repeat the question with the exact names it returns, such as SEV1 instead of Critical.

Rootly rate-limited the request

Rootly answered 429. The limit is 3,000 reads per API key per minute. Wait a minute and try again. Reconnecting doesn’t reset the limit.

An action item change wasn't applied

If the change was declined or Allow writes is off, nothing was sent to Rootly. If you approved it and the request timed out, ask the agent to list the incident’s action items before retrying. A blind retry can file the same item twice.

Security

• Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
• Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
• Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
• Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.

• Global keys are broad. A Global key reads every team’s incidents. Use a Team key when agents should see only one team.
• One write path. Only action item changes reach Rootly, and Allow writes turns them off entirely.

Related

PagerDuty Connection

Send PagerDuty incidents to Resolve for an RCA

Approvals

Control which action item changes wait for a person