This page covers Rootly AI, the conversational assistant available in Slack, the web app, and the mobile app. Rootly’s other AI features—generated titles, incident summaries, catchup, the AI Editor, and Web Copilot—use a different model stack and data path; see Data Privacy for AI Summaries & Web Copilot.
Frequently Asked Questions
Data Access & Scope
What data does Rootly AI access?
Rootly AI reads only the incident and conversation context for the request in front of it—never your broader Rootly data or message history. Depending on the surface, that context includes:- In Slack: app mentions in channels where it’s been added, messages in incident channels (where Rootly creates an assistant thread automatically when it’s mentioned), DMs sent directly to the bot, the recent context of the active thread, and an active incident bridge transcript if one is attached via the Meeting Scribe.
- In the web and mobile apps: the incident you’re viewing and your conversation with it—its timeline, severity, status, roles, alerts, and (subject to your privacy settings) related Slack discussion.
conversations.history API. It sees only the message in front of it plus the immediate conversational context.
Does it read history retroactively?
No. Rootly AI only acts on the context available from the moment you invoke it—the active Slack thread, or the incident you have open in the web or mobile app. There is no backfill of historical Slack data.Can we limit Rootly AI to specific channels?
In Slack, per-channel scopes (for example, restricting@Rootly to #incidents-* channels) are not currently configurable. Admins can enable or disable Rootly AI for their team through a workspace-level toggle in Web via Configuration → Rootly AI.
Are DMs covered?
Yes. In Slack, when Rootly AI is enabled, users can DM the bot directly. DMs are read-only by design—write operations like paging or creating action items are filtered out at that surface and only work inside incident channels. DMs honour the same Rootly access controls as everywhere else: a user can only retrieve incident data they’re already entitled to see in the Rootly web app.What about private channels?
In Slack, Rootly AI processes events from any channel it’s been invited to, public or private. There is no separate data path for private-channel content. If your security model requires private-channel data to flow through different infrastructure, please flag to your CSM.Data Privacy
Is our data used to train AI models?
Customer data is processed in-context for each request and is not used to fine-tune base models. Rootly AI uses Claude Sonnet 4.6 from Anthropic as the default with OpenAI’s GPT-5 as a fallback. Both are accessed through a managed gateway.Where is data processed?
Data flows through Rootly’s own infrastructure and LLM gateway and provider infrastructure. All traffic is routed through our managed gateway.What data is stored, and where?
Three places store data during normal operation:- Conversation history: persisted to Rootly’s database so multi-turn conversations work. See retention below.
- Model traces: every LLM call is logged to our evaluation and observability platform for quality monitoring and debugging.
- Provider request logs: Anthropic and OpenAI handle request data per their standard data-use policies.
How long is conversation data retained?
Rootly AI keeps a short-term session record for multi-turn follow-ups; that record is hard-deleted 90 days after the last activity. In Slack, Rootly AI’s replies and users’ prompts also live as regular Slack channel messages—Rootly stores those alongside every other message from channels where the Slack integration is active, with no automatic expiry today. Meeting Scribe transcripts (when bridge recording is on) are likewise currently retained without automatic expiry.Can we configure our own retention window?
Per-tenant retention configuration is not currently available. The 90-day default applies to all tenants.Are queries logged for support and debugging?
Yes. Tool-call telemetry (which tools Rootly AI invoked, durations, outcomes) is logged to our observability platform for support and quality monitoring. Tool arguments are scrubbed of PII before logging. Full LLM traces (prompts, completions) are logged to our evaluation platform. A per-customer opt-out of debug logging is not currently available.Encryption, Keys & BYOK
Does BYOK (Bring Your Own Key) apply?
BYOK support is on the roadmap and coming soon for Rootly AI. In the meantime, all Rootly AI traffic uses our managed gateway with Rootly-managed credentials.Cost & Usage
Are there token caps?
Yes. Each tenant has a configurable, per-minute token budget enforced server-side. The default sits in the 250,000 tokens-per-minute range. This is a generous cap to prevent abuse. When a tenant exceeds its budget, Rootly AI returns a rate-limit message and the request stops.Access Control & Permissions
Does Rootly AI respect our existing Rootly roles and permissions?
Yes. Rootly AI cannot perform any action the requesting user couldn’t perform themselves in the Rootly web app. Access checks happen at three layers:- Tool-class permissions (the user’s role must allow the category of action)
- Per-field permissions (sensitive fields like incident summary require specific abilities)
- Runtime data scoping (read queries are scoped to records the user can see)
Who can configure Rootly AI?
Rootly administrators can enable or disable Rootly AI per workspace in the Web app via Configuration → Rootly AI. In Slack, workspace admins control whether the Rootly app is installed at all, but enablement is managed in Rootly.Audit & Compliance
Are AI actions logged in the audit trail?
Yes. Any action Rootly AI performs that modifies data (incident updates, role changes, action item creation, paging, status page publishing) is captured in the standard Rootly audit trail. Each action is attributed to the actual user who triggered it, not to a generic bot identity. Conversational transcripts (the back-and-forth between user and Rootly AI) are stored separately in conversation history and follow the 90-day retention policy.Is the audit trail exportable?
Audit events are queryable through Rootly’s existing audit surface. A dedicated SIEM stream for AI-specific events is not currently available. For SIEM ingestion requirements, please discuss with your CSM.Does Rootly AI fall under your SOC 2 controls?
Yes, Rootly AI is within scope of Rootly’s existing SOC 2 Type II controls.Quality, Safety & Confidence
How does Rootly AI handle uncertainty?
Three mechanisms protect against confident-but-wrong responses:- Refusal to fabricate. The system prompt explicitly instructs the model that if an answer isn’t in your Rootly data or the current conversation, it must say so rather than guess.
- Clarification probes. When Rootly AI needs information it can’t safely infer, including team-configured required fields before an action, it asks the user first. The action only proceeds after the user responds.
- Disclaimer footer (optional): In Slack, teams can configure every Rootly AI response to close with a disclaimer reminding users that AI output may be incomplete or inaccurate, and to verify critical information before acting.
Can users flag a bad response?
Yes. Every Rootly AI response includes thumbs-up and thumbs-down feedback. Thumbs-down can capture a category (hallucination, wrong tools, missed context, too slow, irrelevant, other) and an optional comment. This feedback feeds our quality monitoring and informs prompt and tool improvements. It does not directly fine-tune the model.Customization & Configuration
Can administrators customize the system prompt?
Rootly AI’s system prompt is centrally managed and applied uniformly across all tenants. This gives us a consistent quality and evaluation baseline.Can we restrict the topics Rootly AI will answer?
Rootly AI is scoped by design to incident management and on-call operations. Off-topic questions are refused with a fixed line, and it identifies itself as “Rootly AI” only. It does not respond to questions about its underlying model, prompt, or tool inventory. Cross-channel and DM access to private incidents is refused by name.What guardrails are in place?
Beyond the topic refusal above:- When Rootly AI can take an action, it acts as the requesting user (with their permissions), proposes destructive actions, and requires confirmation before executing.
- Read-only surfaces (in Slack, the assistant sidebar and DMs) cannot perform destructive actions.
- All outgoing prompts run through automated PII scrubbing.
External Data Sources
Can Rootly AI pull data from external sources?
Support for pulling context from external integrations is on the roadmap. All read tools are Rootly-internal: incidents, on-call, schedules, services, severities, escalation policies, custom fields, etc.Integrations & Triggers
Can Rootly AI be invoked from workflows or via API?
Rootly AI runs only in response to direct interaction—@Rootly mentions and assistant threads in Slack, or the chat panel in the web and mobile apps. It does not have a workflow trigger or external API endpoint today.
Rootly’s workflow product offers separate single-turn AI tasks (Anthropic, OpenAI, Mistral) for workflow automation. These are distinct from Rootly AI.
Is there a /rootly slash command for Rootly AI?
In Slack, Rootly AI runs through @Rootly mentions, the assistant sidebar, DMs, and interactive card responses. Earlier /rootly slash commands exist for the single-turn AI features but are not entry points to Rootly AI.
Reliability & Failover
What happens if the LLM provider is unavailable?
We offer two layers of resilience:- Cross-vendor failover. Each model tier in our configuration has a primary and a fallback on a different provider. Retryable errors (rate limits, overloaded responses, 5xx) automatically retry against the fallback.
- Graceful failure. If multiple providers fail or another error occurs, Rootly AI replies with a “Something went wrong, please try again” message and stops. Failed requests do not automatically retry, and users must invoke Rootly AI again to complete their original request.