Integrations
Connect Runframe to Datadog, Sentry, Prometheus, AWS CloudWatch, Jira, Google Meet, Custom Webhooks, and more. Learn webhook setup and field mapping.
Integrations
Connect Runframe to your existing monitoring, alerting, and communication tools.
Overview
Runframe integrates with the tools you already use to create incidents automatically and streamline incident response. Reduce toil and ensure no alert goes unnoticed.
Why integrate?
| Benefit | Explanation |
|---|---|
| Automatic incident creation | Alerts create incidents without manual intervention |
| Faster response | Page the right people immediately |
| Single pane of glass | Manage incidents from Slack without tool-switching |
| Deduplication | Same alert doesn't create duplicate incidents |
Slack
Runframe's deepest integration is with Slack, your incident command center.
Features
| Feature | Description |
|---|---|
| Slash commands | Create and manage incidents from Slack |
| Incident channels | Dedicated channels for each incident |
| Notifications | Real-time updates in Slack |
| Interactive modals | Rich forms for incident creation |
| Status syncing | Incident status updates post to channels |
Installation
- Visit the Slack App Directory or use the link from your Runframe dashboard
- Click Add to Slack
- Grant Runframe permissions:
- Create channels
- Send messages
- View user information
- Complete installation and sign in to Runframe
Slash commands
Once installed, use these commands from any Slack channel:
| Command | Description |
|---|---|
/inc create | Create a new incident |
/inc assign | Assign responders |
/inc move | Update incident status |
/inc severity | Change severity |
/inc update | Post a status update |
/inc resolve | Mark as resolved |
/inc close | Archive the channel |
/inc page | Page the on-call |
See the Slash Commands guide for complete documentation.
Incident channel naming
Runframe creates incident channels with a consistent naming pattern:
{incident-number}-{title-slug}Example: inc-00042-api-latency-spike
The channel name is derived from the incident number and a slugified version of the title (max 80 characters).
Datadog
Create incidents automatically from Datadog monitors and alerts.
Setup from Runframe
- Navigate to Settings → Integrations
- Click Connect next to Datadog — this generates a unique webhook URL for your organization
- Copy the webhook URL (format:
https://api.runframe.io/webhooks/{routingKey}) - Link services to route Datadog alerts to specific Runframe services
Setup from Datadog
- In Datadog, navigate to Integrations → Webhooks
- Create a new webhook with your Runframe webhook URL
- Add the
service_idtag to your monitors (e.g.,service_id:SER-00001) - Customize the payload to include incident details
- Associate the webhook with your monitors
Datadog to Runframe field mapping
| Datadog field | Runframe field |
|---|---|
| Monitor name | Incident title |
| Monitor query | Description |
| Alert priority (P1–P5) | Severity (mapped to SEV0–SEV4) |
service_id tag | Routes to specific service |
| Alert snapshot | Link to Datadog dashboard |
Datadog severity mapping
Configure how Datadog alert priorities map to Runframe severities:
| Datadog priority | Default Runframe severity |
|---|---|
| P1 | Critical (SEV0) |
| P2 | High (SEV1) |
| P3 | Medium (SEV2) |
| P4 | Low (SEV3) |
| P5 | Minimal (SEV4) |
Customize severity mapping
Adjust severity mapping per monitor based on your service's priorities. A "low" priority database alert might be P1 if database is business-critical.
Sentry
Create incidents from Sentry error events and alerts.
Sentry setup
- Navigate to Settings → Integrations
- Click Connect next to Sentry — this generates a unique webhook URL for your organization
- Copy the webhook URL (format:
https://api.runframe.io/webhooks/{routingKey}) - Link services to route Sentry alerts to specific Runframe services
- Configure which projects and alert rules should create incidents
Sentry to Runframe field mapping
| Sentry field | Runframe field |
|---|---|
| Issue title | Incident title |
| Issue message | Description |
| Issue level | Severity (see mapping below) |
| Project slug | Routes to specific service (matched by slug) |
| First seen | Detection time |
| Event count | Impact indicator |
Sentry severity mapping
| Sentry level | Default Runframe severity |
|---|---|
| Fatal | Critical (SEV0) |
| Error | Critical (SEV0) |
| Warning | Medium (SEV2) |
| Info | Minimal (SEV4) |
| Debug | Minimal (SEV4) |
Prometheus
Create incidents from Prometheus alert rules via Alertmanager.
Prometheus setup
- Navigate to Settings → Integrations
- Click Connect next to Prometheus — this generates a unique webhook URL for your organization
- Copy the webhook URL (format:
https://api.runframe.io/webhooks/{routingKey}) - Link services to route Prometheus alerts to specific Runframe services
- In Alertmanager, configure a webhook receiver with your Runframe URL
Alertmanager configuration
receivers:
- name: 'runframe'
webhook_configs:
- url: 'https://api.runframe.io/webhooks/YOUR_ROUTING_KEY'
send_resolved: trueAssociate the receiver with your alert routes.
Prometheus to Runframe field mapping
| Prometheus field | Runframe field |
|---|---|
| Alert name | Incident title |
| Alert annotations | Description |
service_id label | Routes to specific service |
| Alert severity | Severity (critical → Critical, warning → Medium) |
| Firing time | Detection time |
Prometheus severity mapping
| Prometheus severity | Default Runframe severity |
|---|---|
| Critical | Critical (SEV0) |
| Warning | Medium (SEV2) |
| Info | Minimal (SEV4) |
Alertmanager configuration example
route:
group_by: ['alertname', 'cluster', 'service']
group_wait: 10s
group_interval: 10s
repeat_interval: 12h
receiver: 'runframe'
receivers:
- name: 'runframe'
webhook_configs:
- url: 'https://api.runframe.io/webhooks/YOUR_ROUTING_KEY'
send_resolved: trueKeep your routing key secure
The routing key in your webhook URL is a secret token. Treat it like a password and use secrets management to avoid hardcoding it in config files.
AWS CloudWatch
Create incidents automatically from CloudWatch alarms via SNS.
How it works
CloudWatch alarms publish to an SNS topic, which POSTs to Runframe's webhook endpoint. Runframe verifies the SNS signature, auto-confirms the subscription, and parses the alarm payload to create or resolve incidents.
CloudWatch Alarm → SNS Topic → POST /webhooks/{routingKey} → Runframe IncidentCloudWatch setup
- Navigate to Settings → Integrations
- Click Connect next to CloudWatch — this generates a unique webhook URL for your organization
- Copy the webhook URL (format:
https://api.runframe.io/webhooks/{routingKey})
AWS setup
- Create an SNS topic in the same region as your CloudWatch alarms
- Add a subscription to the SNS topic:
- Protocol: HTTPS
- Endpoint: Your Runframe webhook URL
- Runframe automatically confirms the SNS subscription (no manual action needed)
- Configure your CloudWatch alarms to send notifications to the SNS topic
- Add a
service_iddimension to your metrics for automatic service routing
CloudWatch to Runframe field mapping
| CloudWatch field | Runframe field |
|---|---|
| AlarmName | Incident title |
| AlarmDescription + NewStateReason | Description |
| NewStateValue | Status (see mapping below) |
Trigger.Dimensions service_id | Routes to specific service |
| AlarmArn | AWS Console link for investigation |
| StateChangeTime | Detection time |
CloudWatch alarm state mapping
| CloudWatch state | Runframe status |
|---|---|
| ALARM | New (creates incident) |
| OK | Resolved |
| INSUFFICIENT_DATA | Investigating |
Security
CloudWatch webhooks are verified using two layers:
- SNS signature verification — Runframe cryptographically verifies every SNS message using the certificate-based RSA signature (supports SignatureVersion 1 and 2)
- Routing key — The secret URL acts as an additional authentication layer
Certificate URL validation
Runframe only accepts signing certificates from sns.*.amazonaws.com domains with the expected path pattern. Certificates are cached for 24 hours.
PagerDuty
Coming soon
PagerDuty integration is on the roadmap. In the meantime, you can use the Custom Webhook integration to forward PagerDuty alerts to Runframe via PagerDuty's generic webhook extensions.
Jira
Track incident-related work items and action items directly in Jira.
Connecting Jira
- Navigate to Settings → Integrations → Jira
- Click Connect Jira — you'll be redirected to Atlassian to authorize
- Grant Runframe read/write access to your Jira projects
- Select the default Jira project for incident work items
Features
| Feature | Description |
|---|---|
| Create Jira issues | Create follow-up tickets from incidents |
| Status sync | Jira issue status syncs with Runframe |
| Link to incidents | Jira issues are linked to their source incident |
| Transition issues | Update Jira issue status from Runframe |
Creating a Jira issue from an incident
- Open an incident in the Runframe dashboard
- Click Create Jira Issue in the sidebar
- Select the project, issue type, and fill in details
- The issue is created and linked to the incident
Use Jira for action items
After a postmortem, create Jira issues for each action item to ensure follow-through.
Google Meet
Automatically create Google Meet war rooms for incident coordination.
Connecting Google Meet
- Navigate to Settings → Integrations → Google Meet
- Click Connect Google Meet — you'll be redirected to Google to authorize
- Grant Runframe permission to create meetings on your behalf
How it works
When an incident is created, Runframe can automatically create a Google Meet link and share it in the incident Slack channel. This gives responders an instant video call for coordination.
Configuration
| Setting | Description |
|---|---|
| Auto-create | Automatically create a Meet for incidents above a severity threshold |
| Severity threshold | Only create Meets for SEV0/SEV1 (configurable) |
Custom Webhook
Create incidents from any HTTP source — custom scripts, CI/CD pipelines, Terraform, Zapier, n8n, or any tool that can make an HTTP POST.
Custom webhook setup
- Navigate to Settings → Integrations → Custom Webhook
- Click Connect — this generates a unique webhook URL for your organization
- Copy the webhook URL (format:
https://api.runframe.io/webhooks/{routingKey}) - Configure your tool to POST JSON to this URL
Webhook payload format
Send a JSON payload with these fields:
{
"title": "High memory usage on production servers",
"service_id": "SER-00001",
"description": "Memory usage above 90% on 3 servers",
"severity": "SEV1",
"status": "new",
"source_url": "https://grafana.example.com/dashboard/abc",
"dedup_key": "mem-alert-prod-001",
"metadata": {
"environment": "production",
"region": "us-east-1"
}
}Required and optional fields
| Field | Required | Description |
|---|---|---|
title | Yes | Brief incident summary (max 500 chars) |
service_id | Yes | Service ID to route the incident to (e.g., SER-00001) |
description | No | Detailed description (max 5000 chars) |
severity | No | SEV0, SEV1, SEV2, SEV3, or SEV4 (default: uses fallback chain) |
status | No | new, investigating, or resolved (default: new) |
source_url | No | Link back to the source (dashboard, CI run, etc.) |
dedup_key | No | Deduplication key — same key = same incident (max 255 chars) |
metadata | No | Key-value pairs for additional context (max 10 keys) |
Deduplication
- If
dedup_keyis provided, subsequent POSTs with the same key update the existing incident instead of creating a new one - If
dedup_keyis omitted, every POST creates a new incident
HMAC signature verification (optional)
For stronger security beyond the routing key, enable HMAC-SHA256 signing:
- Generate a signing secret in the integration settings
- Include two headers with each request:
X-Runframe-Signature: sha256=<hex HMAC of timestamp.body>
X-Runframe-Timestamp: <unix seconds>The signature is computed as HMAC-SHA256(signingSecret, "${timestamp}.${body}").
Runframe rejects requests with timestamps older than 5 minutes to prevent replay attacks.
Example: curl
curl -X POST https://api.runframe.io/webhooks/YOUR_ROUTING_KEY \
-H "Content-Type: application/json" \
-d '{
"title": "High memory usage on production servers",
"service_id": "SER-00001",
"description": "Memory usage above 90% on 3 servers",
"severity": "SEV1"
}'Example: curl with HMAC signing
TIMESTAMP=$(date +%s)
BODY='{"title":"Deploy failed","service_id":"SER-00002","severity":"SEV2"}'
SIGNATURE=$(echo -n "${TIMESTAMP}.${BODY}" | openssl dgst -sha256 -hmac "your-signing-secret" | awk '{print $2}')
curl -X POST https://api.runframe.io/webhooks/YOUR_ROUTING_KEY \
-H "Content-Type: application/json" \
-H "X-Runframe-Signature: sha256=${SIGNATURE}" \
-H "X-Runframe-Timestamp: ${TIMESTAMP}" \
-d "${BODY}"Routing key is always required
The routing key in the URL is the baseline security layer. HMAC signing is an optional additional layer for environments where URL secrecy is harder to guarantee.
API
Build custom integrations with the Runframe REST API.
Authentication
All API requests require an API key:
curl https://api.runframe.io/v1/incidents \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"Create an incident
curl https://api.runframe.io/v1/incidents \
-X POST \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"title": "API latency spike",
"severity": "SEV1",
"description": "API response times > 5s",
"affectedServices": ["SERVICE_UUID_HERE"],
"customerFacing": true
}'Update an incident
curl https://api.runframe.io/v1/incidents/INC-042 \
-X PATCH \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"status": "identified"
}'See the API reference for complete documentation.
Testing integrations
After setting up an integration, verify it works correctly.
Test incident creation
- Trigger a test alert from your monitoring tool (or use
curlfor Custom Webhook) - Verify Runframe creates the incident
- Check that field mapping is correct (title, severity, service routing)
- Confirm the right people were notified
Webhook event logs
Runframe logs all incoming webhook events for debugging:
- Navigate to Settings → Integrations
- View recent webhook deliveries and any parsing errors
Best practices
Integration strategy
Do:
- Start simple – Begin with 1 to 2 critical integrations
- Test thoroughly – Verify integrations work before relying on them
- Document customizations – Keep records of field mappings and severity rules
- Monitor health – Check integration status regularly
Don't:
- Don't create duplicate incidents – Deduplicate alerts from multiple sources
- Don't over-automate – Manual control for high-severity incidents
- Don't ignore errors – Failed webhooks need investigation
- Don't set and forget – Review integration quarterly
Reducing alert noise
Integrations can create too many incidents. Reduce noise:
- Aggregate alerts – Group similar alerts into a single incident
- Set thresholds – Only create incidents for alerts exceeding severity
- Time-based windows – Suppress repeated alerts within a time window
- Smart deduplication – Link duplicate incidents instead of creating new ones
Alert fatigue is real
Too many incidents train teams to ignore notifications. Be selective about which alerts create incidents.
Need more?
- Slash Commands – Complete
/inccommand reference - Incidents – Incident lifecycle and severity
- On-Call – Scheduling and rotations
- Webhooks – Custom webhook integrations
- Web Dashboard – Integration management UI
Escalations
Configure automatic escalation policies in Runframe. Set response timers, backup responders, and emergency manager escalation paths.
Webhooks API
Runframe webhooks API reference. Create incidents from Datadog, Sentry, Prometheus, CloudWatch, and Custom Webhooks. Learn payload format, authentication, and examples.