Overview
Permissions in Rootly are managed through roles, which determine what actions a user can perform within a team. Roles are intentionally team-scoped and product-specific, giving organizations fine-grained control over access. Each team membership assigns two roles to a user:- An Incident Response role, which governs incident creation, management, configuration, and analytics.
- An On-Call role, which governs alerting, paging, schedules, escalation policies, and responder workflows.
Permissions are evaluated per team. A user may have different access levels across different teams within the same Rootly workspace.
Default Roles
Rootly ships with system-defined roles for both Incident Response and On-Call. These roles are created automatically for every team and cannot be deleted. Some roles are editable, while others are intentionally fixed.Incident Response Roles
Incident Response includes the following default roles:- Owner
- Admin
- User
- Observer
- No Access
Owner
Owner
Owners have full access to Incident Response. They can configure all incident-related settings, manage workflows and integrations, access all incident data (including private incidents), and administer platform-level features such as billing. This role is typically reserved for platform owners or the core incident management team.
Admin
Admin
Admins can configure and manage most Incident Response features, including incident properties, workflows, retrospectives, and integrations. This role is ideal for teams responsible for maintaining and improving incident processes.
User
User
Users are standard incident participants. They can respond to incidents, update incident details, assign roles, and collaborate during active incidents, without having broad administrative permissions.
Observer
Observer
Observers have primarily read access but can still create incidents. This makes the role suitable for cross-functional teams such as support, operations, or customer success, who need visibility into incidents and the ability to raise issues.
No Access
No Access
No Access removes Incident Response permissions entirely for the team. This is useful when a user only needs On-Call access or should not interact with incidents in a given team.
On-Call Roles
On-Call includes a separate set of default roles:- Admin
- User
- Observer
- No Access
Admin
Admin
On-Call Admins can manage all on-call configuration, including schedules, escalation policies, routing rules, alert sources, and advanced features like Live Call Routing and Heartbeats.
User
User
On-Call Users are standard responders. They receive alerts, can acknowledge and resolve them, and participate in on-call rotations without managing configuration.
Observer
Observer
On-Call Observers have limited access but can typically initiate paging. This role is commonly used for teams that need to trigger alerts without owning on-call configuration.
No Access
No Access
No Access removes all On-Call permissions for the team. Users with this role will not receive alerts or interact with paging features.
Custom
Custom
Custom roles allow teams to define precise On-Call access, such as allowing alert acknowledgement without permission to edit schedules or escalation policies.
On-Call does not include an Owner role. Administrative control is handled through Admin and Custom roles.
Permission Sets
Permission sets define what actions a role can perform on a specific entity. Each permission set typically includes some combination of:- Create
- Read
- Update
- Delete
Incident Response Permission Sets
| Entity | Description | Links & Examples |
|---|---|---|
| Alerts | View and create alert events sent to Rootly from external sources. Alerts cannot be deleted. Status updates are handled by On-Call permissions. | https://rootly.com/account/alerts |
| API Keys | Manage API tokens used to authenticate with Rootly APIs. | |
| Audits | View the audit log of configuration and permission changes. | https://rootly.com/account/audits |
| Causes | Manage incident cause classifications used for analysis and reporting. | https://rootly.com/account/causes |
| Custom Fields | Manage custom incident fields used to capture additional metadata. | https://rootly.com/account/form-fields |
| Environments | Manage environment labels used to categorize incidents. | https://rootly.com/account/environments |
| Functionalities | Manage functionality labels representing impacted features or systems. | https://rootly.com/account/functionalities |
| Incident Feedback | Manage feedback collected during or after incident resolution. | |
| Incident Roles | Define roles assigned to responders during incidents. | https://rootly.com/account/incident-roles |
| Incident Types | Manage categories used to classify incidents. | https://rootly.com/account/incident-types |
| Incidents | Manage public incident records, including status, severity, roles, and impacted services. | https://rootly.com/account/incidents |
| Integrations | Manage native integrations with external systems. | https://rootly.com/account/integrations |
| Invitations | Invite users to join your Rootly workspace. | https://rootly.com/account/invitations |
| Playbooks | Manage playbooks used during incidents. | https://rootly.com/account/playbooks |
| Private Incidents | Manage private incidents with restricted visibility. | |
| Pulses | Manage CI/CD and deployment events sent to Rootly. | https://rootly.com/account/pulses |
| Retrospective | Manage retrospective processes and templates. | https://rootly.com/account/retrospective-processes |
| Roles | Manage Incident Response roles and permissions. | https://rootly.com/account/roles |
| Teams | Manage teams participating in incidents. | https://rootly.com/account/teams |
| Secrets | Manage secrets used securely in workflows. | https://rootly.com/account/secrets |
| Services | Manage services associated with incidents. | https://rootly.com/account/services |
| Severities | Manage severity levels used to classify incidents. | https://rootly.com/account/severities |
| Status Pages | Manage Rootly-hosted status pages. | https://rootly.com/account/status-pages |
| Webhooks | Manage outbound webhooks for incident and alert events. | https://rootly.com/account/webhooks/outgoing/endpoints |
| Workflows | Manage automation workflows triggered by incident events. | https://rootly.com/account/workflows |
On-Call Permission Sets
On-Call permission sets control paging, alert handling, and responder operations.These permissions determine how alerts are created, routed, escalated, acknowledged, and resolved, as well as who can configure the systems that support on-call coverage. Unlike Incident Response permissions, On-Call permissions are focused on real-time operational behavior and responder availability.
| Entity | Description |
|---|---|
| Alerts | Create, view, acknowledge, resolve, and re-trigger alerts. Controls the alert lifecycle once paging has begun. |
| Alert Groups | Manage alert grouping rules used to reduce noise and consolidate related alerts. |
| Alert Sources | Configure inbound alert sources and define how external alerts enter Rootly. |
| Alert Routing Rules | Define routing logic that determines which team, service, or escalation policy an alert is sent to. |
| Alert Urgencies | Manage urgency levels that control escalation behavior and notification intensity. |
| Schedules | Manage on-call schedules and rotations that determine who is on duty at any given time. |
| Schedule Overrides | Create temporary overrides to adjust on-call coverage outside of normal rotations. |
| Escalation Policies | Configure escalation paths, levels, repeat behavior, and working-hours logic for paging. |
| Live Call Routing | Manage inbound phone numbers, IVR calling trees, voicemail behavior, and live call escalation. |
| Heartbeats | Configure heartbeat monitors used to detect when systems stop checking in. |
| On-Call Roles | Manage On-Call roles and permission assignments for team members. |
| On-Call Readiness Reports | View and manage reports that assess coverage, responsiveness, and on-call health. |
| Services | Manage services used for alert routing and ownership in on-call workflows. |
| Teams | Manage teams used as alert routing targets and on-call ownership groups. |
| Integrations | Manage alerting and paging integrations (monitoring tools, incident systems, etc.). |
| Webhooks | Manage outbound webhooks that emit alert and on-call events. |
| API Keys | Manage API tokens used for on-call and alerting integrations. |
On-Call permissions govern who gets paged and how alerts behave.
They are evaluated independently from Incident Response permissions, which control incident records, workflows, and retrospectives.
They are evaluated independently from Incident Response permissions, which control incident records, workflows, and retrospectives.
Best Practices
- Assign the minimum permissions required for each role.
- Use Observers to provide visibility without administrative access.
- Separate Incident Response administration from On-Call ownership where possible.
- Restrict Private Incident access to a small, trusted group.
- Clearly document Custom On-Call roles so future administrators understand their intent.
Troubleshooting
A user can view alerts but cannot acknowledge or resolve them
A user can view alerts but cannot acknowledge or resolve them
This usually indicates missing On-Call permissions. Confirm the user’s On-Call role includes alert update access for the relevant team.
A user can page but cannot edit schedules or escalation policies
A user can page but cannot edit schedules or escalation policies
Paging and configuration permissions are separate by design. Assign an On-Call role that includes schedule and escalation policy management if needed.
A user can see public incidents but not private incidents
A user can see public incidents but not private incidents
Private incidents are controlled separately. Ensure the user’s Incident Response role includes Private Incident access for the team.
Role changes fail or revert unexpectedly
Role changes fail or revert unexpectedly
This can occur when seat limits are reached. Rootly may block assigning active roles if no seats are available.
A user has the correct role but still cannot perform an action
A user has the correct role but still cannot perform an action
Verify the user is operating within the correct team context and that the permission applies to the correct product (Incident Response vs On-Call).