Slash Commands

All Slack commands for managing incidents from Slack.

Overview

Runframe’s Slack commands use the /inc prefix. Commands work in any channel, but most incident-specific commands require an active incident context.

/inc create

Create a new incident from any Slack channel.

Usage

/inc create

What happens

1. A modal appears prompting for incident details
2. Runframe creates a dedicated Slack channel (inc-YYYY-MM-DD-###)
3. Assigned responders are notified
4. SLA deadlines are set based on severity

Fields

/inc assign

Assign a person to an incident or change existing assignments.

Usage

/inc assign @username

In incident channels

When used in an incident channel, assigns the user to that incident.

In other channels

When used outside an incident channel, prompts you to select which incident to assign them to.

Incident roles

For larger incidents, you can assign specific roles:

/inc assign @username --role lead
/inc assign @username --role comms
/inc assign @username --role operations

/inc status

Update the current status of an incident.

Usage

/inc status investigating
/inc status identified
/inc status monitoring
/inc status resolved

Available statuses

What happens

• Status update posts to the incident channel
• Dashboard incident detail page updates
• Timestamp recorded for MTTA/MTTR analytics

/inc severity

Change the severity level of an incident.

Usage

/inc severity p0
/inc severity p1
/inc severity p2
/inc severity p3
/inc severity p4

Severity levels

What happens

• Severity badge updates in Slack and dashboard
• SLA deadlines recalculate based on new severity
• Incident events log records the change

/inc update

Post a narrative status update to an incident.

Usage

/inc status investigating
/inc update We're seeing increased error rates on the API gateway. Investigating logs now.

Or inline:

/inc update Deployed hotfix to production. Monitoring error rates.

When to use

Use /inc update for:

• Narrative context beyond status changes
• Explaining what you’re doing during investigation
• Sharing findings before root cause is identified
• Providing ETAs or progress updates

Difference from /inc status

/inc resolve

Mark an incident as resolved and trigger post-incident workflow.

Usage

/inc resolve

What happens

1. Incident status changes to “Resolved”
2. Resolution timestamp is recorded for MTTR
3. You’re prompted for:
   • Brief resolution summary
   • Whether to start a postmortem (PM-###)
4. Incident channel remains available for reference

Resolution summary

Provide a concise explanation:

Fixed database connection pool leak. Deployed patch v2.3.1.
Connection pool size increased from 10 to 50. Error rates back to normal.
Monitoring for 24 hours.

Postmortem prompt

Runframe will ask if you want to start a postmortem. Options:

• Yes – Creates PM-### document with pre-filled incident data
• Later – No postmortem created, you can start one manually
• Skip – No postmortem needed for minor incidents

/inc close

Archive an incident channel and remove it from active view.

Usage

/inc close

When to use

After an incident is resolved and all follow-up is complete:

• Postmortem is written (if applicable)
• Action items are assigned
• Stakeholders have been notified

What happens

• Incident channel is archived in Slack
• Incident removed from active dashboard view
• Still accessible in “All incidents” and search

/inc page

Page the current on-call engineer for a service.

Usage

/inc page

Or for a specific service:

/inc page api-backend

What happens

1. Runframe identifies the on-call engineer for the service
2. Sends them a notification (Slack DM, SMS, or phone call based on severity)
3. Posts to the channel who was paged and when

On-call targeting

If no service specified, pages the on-call for:

• Services affected by the current incident (if in incident channel)
• Default service configured for your team

Tips and best practices

Creating incidents

• Be specific in titles – “API 500 errors on checkout” vs “API broken”
• Set severity correctly – Avoid severity fatigue; P0 should be rare
• List affected services – Helps route to the right on-call engineer

During incidents

• Post regular updates – Even “still investigating” manages expectations
• Use threads for side discussions – Keep channel focused on status
• Escalate early if stuck – Use /inc page or escalate manually if needed

After incidents

• Always resolve – Don’t leave incidents in “monitoring” indefinitely
• Write postmortems for P0-P2 – Capture learnings while fresh
• Close channels promptly – Reduce clutter, but keep reference

Need more?

• Incidents – Incident lifecycle and severity
• On-Call – Scheduling and rotations
• Web dashboard – Full incident management UI