This page covers @Rootly in Slack, the conversational assistant. Rootly’s other AI features—summaries, catchup, generated titles, the AI Editor, and Web Copilot—are documented in Data Privacy for AI Summaries & Web Copilot.
Frequently Asked Questions
Data Access & Scope
What data does the assistant access?
The assistant reads only what arrives through the Slack events it’s subscribed to. This includes:- 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 it’s running in
- An active incident bridge transcript, if one is attached via the Meeting Scribe
conversations.history API. It sees only the message in front of it plus the immediate conversational context.
Does it read history retroactively?
No. The assistant only sees messages from activation forward, and only the ones that flow through the active thread. There is no backfill of historical Slack data.Can we limit the assistant to specific channels?
Per-channel scopes (for example, restricting@Rootly to #incidents-* channels) is not currently configurable. Admins can enable or disable the assistant in Slack for their team through a workspace-level toggle in Web via Configuration → Rootly AI.
Are DMs covered?
Yes. When the assistant is enabled, users can DM the bot directly. DMs are read-only by design. This means write operations like paging, creating action items, etc. are filtered out at the message surface and only work inside incident channels. DMs honour the same Rootly access controls as in-channel use. A user can only retrieve incident data they’re already entitled to see in the Rootly web app.What about private channels?
The assistant 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. The assistant 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: This is 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?
The Slack assistant’s replies and users’ prompts 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. The assistant also keeps a short-term session record for multi-turn follow-ups; that one is hard-deleted 90 days after the last activity. Lastly, the Meeting Scribe transcripts (when bridge recording is on) are 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 the assistant 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 the Slack assistant. In the meantime, all Slack assistant 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, the assistant returns a rate-limit message and the request stops.Access Control & Permissions
Does the assistant respect our existing Rootly roles and permissions?
Yes. The assistant 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)
Are DMs subject to the same controls?
Yes. The DM surface uses the same access controls as in-channel use. A user can only read data they’re entitled to see.Who can configure the assistant?
Rootly administrators can enable or disable the assistant per workspace in the Web app via Configuration → Rootly AI. Slack workspace admins control whether the Rootly app is installed at all, but the assistant’s enablement is managed in Rootly.Audit & Compliance
Are AI actions logged in the audit trail?
Yes. Any action the assistant 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 Slack user who triggered it, not to a generic bot identity. Conversational transcripts (the back-and-forth between user and assistant) 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 the AI assistant fall under your SOC 2 controls?
Yes, the AI assistant is within scope of Rootly’s existing SOC 2 Type II controls.Quality, Safety & Confidence
How does the assistant 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 the assistant needs information it can’t safely infer, including team-configured required fields before an action, it posts an interactive card asking the user. The action only proceeds after the user responds.
- Disclaimer footer (optional): Teams can configure every assistant’s response in Slack 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 assistant response includes thumbs-up and thumbs-down feedback buttons. Selecting thumbs-down opens a categorized feedback modal (hallucination, wrong tools, missed context, too slow, irrelevant, other) with an optional comment field. Feedback is also available on the interactive cards the assistant posts when asking clarifying questions or confirming actions. 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?
The Slack assistant’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 the assistant will answer?
The assistant is scoped by design to incident management and on-call operations. Off-topic questions are refused with a fixed line, and the assistant 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:- Write tools are scoped to incident channels; the read-only/sidebar/DM surfaces cannot perform destructive actions.
- The assistant proposes destructive actions and requires user confirmation before executing.
- All outgoing prompts run through automated PII scrubbing.
External Data Sources
Can the assistant 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 the assistant be invoked from workflows or via API?
The Slack assistant is event-driven and runs only in response to Slack interactions (app mentions, assistant thread messages, DMs, button clicks). 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 the Slack assistant.Is there a /rootly slash command for the assistant?
The assistant 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 the assistant.
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, the assistant replies with “Something went wrong, please try again” message and stops. Failed requests do not automatically retry, and users must invoke the bot again to complete their original request.