salesforce-incident-runbook
Execute Salesforce incident response procedures with triage, mitigation, and postmortem. Use when responding to Salesforce-related outages, investigating API errors, or running post-incident reviews for Salesforce integration failures. Trigger with phrases like "salesforce incident", "salesforce outage", "salesforce down", "salesforce on-call", "salesforce emergency", "salesforce broken".
Best use case
salesforce-incident-runbook is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Execute Salesforce incident response procedures with triage, mitigation, and postmortem. Use when responding to Salesforce-related outages, investigating API errors, or running post-incident reviews for Salesforce integration failures. Trigger with phrases like "salesforce incident", "salesforce outage", "salesforce down", "salesforce on-call", "salesforce emergency", "salesforce broken".
Teams using salesforce-incident-runbook should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/salesforce-incident-runbook/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How salesforce-incident-runbook Compares
| Feature / Agent | salesforce-incident-runbook | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Execute Salesforce incident response procedures with triage, mitigation, and postmortem. Use when responding to Salesforce-related outages, investigating API errors, or running post-incident reviews for Salesforce integration failures. Trigger with phrases like "salesforce incident", "salesforce outage", "salesforce down", "salesforce on-call", "salesforce emergency", "salesforce broken".
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
AI Agents for Marketing
Discover AI agents for marketing workflows, from SEO and content production to campaign research, outreach, and analytics.
SKILL.md Source
# Salesforce Incident Runbook
## Overview
Rapid incident response procedures for Salesforce integration failures, covering Salesforce-side outages, API limit exhaustion, authentication failures, and data sync issues.
## Prerequisites
- Salesforce CLI authenticated (`sf org login`)
- Access to Salesforce Status API
- Monitoring dashboards configured (see `salesforce-observability`)
- Communication channels (Slack, PagerDuty)
## Quick Triage (Do This First)
```bash
# 1. Is Salesforce itself down?
curl -s https://api.status.salesforce.com/v1/incidents/active | jq '.[0:3]'
# If incidents returned → Salesforce-side issue, enable fallback mode
# 2. Check your org's instance status
# Find your instance at: https://status.salesforce.com
curl -s "https://api.status.salesforce.com/v1/instances/NA45/status" | jq '.status'
# 3. Check API limits — are we out of calls?
sf limits api display --target-org my-org --json | jq '.result[] | select(.name == "DailyApiRequests")'
# If remaining = 0 → API_LIMIT_EXCEEDED, see mitigation below
# 4. Check authentication
sf org display --target-org my-org --json | jq '.result.connectedStatus'
# If "RefreshTokenError" → re-authenticate
# 5. Check recent errors in your logs
sf apex log list --target-org my-org --json | jq '.result[0:5]'
```
## Decision Tree
```
Integration returning errors?
├── YES: Is status.salesforce.com showing incident?
│ ├── YES → Salesforce outage. Enable fallback mode. Monitor status page.
│ └── NO → Check error type below:
│ ├── INVALID_SESSION_ID (401) → Token expired. Re-authenticate.
│ ├── REQUEST_LIMIT_EXCEEDED (403) → API limit hit. Reduce calls.
│ ├── UNABLE_TO_LOCK_ROW (409) → Record contention. Retry with backoff.
│ ├── MALFORMED_QUERY / INVALID_FIELD → Code bug. Check SOQL.
│ └── 500/503 → Salesforce-side. Wait and retry.
└── NO: Is data syncing correctly?
├── YES → Likely resolved or intermittent. Monitor.
└── NO → Check CDC subscription, query timestamps, bulk job status.
```
## Immediate Actions by Error Type
### REQUEST_LIMIT_EXCEEDED — API Limit Exhausted
```typescript
// This is a P1 — your integration is completely blocked
// 1. Check what's consuming API calls
const limits = await conn.request('/services/data/v59.0/limits/');
console.log('API calls:', limits.DailyApiRequests);
console.log('Bulk API:', limits.DailyBulkV2QueryJobs);
// Limits reset on a 24-hour rolling basis
// 2. Identify top consumers (Enterprise+ orgs with EventLogFile)
const topUsers = await conn.query(`
SELECT UserId, COUNT(Id) callCount
FROM EventLogFile
WHERE EventType = 'API' AND LogDate = TODAY
GROUP BY UserId
ORDER BY COUNT(Id) DESC
LIMIT 10
`);
// 3. Immediate mitigation: pause non-critical integrations
// Set env var: SF_CRITICAL_ONLY=true
// Only allow essential operations (auth, health check, critical writes)
```
### INVALID_SESSION_ID — Authentication Failure
```bash
# Token expired or revoked — re-authenticate
sf org login web --alias my-org --instance-url https://login.salesforce.com
# For CI/automated: re-auth with JWT
sf org login jwt \
--client-id $SF_CLIENT_ID \
--jwt-key-file server.key \
--username $SF_USERNAME \
--alias my-org
# Verify connection is restored
sf org display --target-org my-org
```
### Salesforce System Outage
```typescript
// Enable graceful degradation — serve stale data from cache
const FALLBACK_MODE = process.env.SF_FALLBACK_MODE === 'true';
async function queryWithFallback<T>(soql: string, cacheKey: string): Promise<T[]> {
if (FALLBACK_MODE) {
const cached = await redis.get(cacheKey);
if (cached) {
console.warn('SF FALLBACK: serving cached data');
return JSON.parse(cached);
}
throw new Error('Salesforce unavailable and no cached data');
}
const conn = await getConnection();
const result = await conn.query<T>(soql);
// Always update cache for fallback
await redis.set(cacheKey, JSON.stringify(result.records), 'EX', 3600);
return result.records;
}
```
## Communication Templates
### Internal (Slack)
```
P1 INCIDENT: Salesforce Integration
Status: INVESTIGATING
Error: [REQUEST_LIMIT_EXCEEDED / INVALID_SESSION_ID / SF outage]
Impact: [Data sync paused / API calls failing / user-facing errors]
Current action: [Checking limits / re-authenticating / enabling fallback]
Next update: [time]
```
### Postmortem Template
```markdown
## Incident: Salesforce [Error Type]
**Date:** YYYY-MM-DD | **Duration:** X hours | **Severity:** P[1-4]
### Summary
[One sentence — e.g., "API limit exhausted due to unoptimized batch job"]
### Root Cause
[e.g., "New sync job ran SELECT * on Contact (3M records) using individual queries instead of Bulk API"]
### Impact
- API calls blocked for [duration]
- [N] users affected / [N] records not synced
### Timeline
- HH:MM — Alerts fired: REQUEST_LIMIT_EXCEEDED
- HH:MM — Triage: identified bulk sync as consumer
- HH:MM — Mitigated: paused sync job
- HH:MM — Resolved: API limit rolled over
### Action Items
- [ ] Migrate sync to Bulk API 2.0 — @owner — due date
- [ ] Add API budget guard (80% warning) — @owner — due date
- [ ] Set up EventLogFile monitoring for top consumers — @owner — due date
```
## Error Handling
| Issue | Cause | Solution |
|-------|-------|----------|
| Can't reach status API | Network issue | Try https://status.salesforce.com manually |
| sf CLI auth expired | Token revoked | Re-authenticate with `sf org login` |
| Limits API returns 403 | Limit already exceeded | Wait for rolling 24hr reset |
| Bulk job stuck | Processing timeout | Abort and retry: `sf data bulk delete` |
## Resources
- [Salesforce Status API](https://api.status.salesforce.com/)
- [Salesforce Trust Site](https://status.salesforce.com)
- [API Limits Quick Reference](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)
## Next Steps
For data handling, see `salesforce-data-handling`.Related Skills
responding-to-security-incidents
Analyze and guide security incident response, investigation, and remediation processes. Use when you need to handle security breaches, classify incidents, develop response playbooks, gather forensic evidence, or coordinate remediation efforts. Trigger with phrases like "security incident response", "ransomware attack response", "data breach investigation", "incident playbook", or "security forensics".
windsurf-incident-runbook
Execute Windsurf incident response when AI features fail or cause production issues. Use when Cascade breaks code, Windsurf service is down, AI-generated code causes production incidents, or team needs emergency Windsurf troubleshooting. Trigger with phrases like "windsurf incident", "windsurf outage", "windsurf broke production", "cascade caused bug", "windsurf emergency".
webflow-incident-runbook
Execute Webflow incident response — triage by HTTP status (401/403/429/500), circuit breaker activation, cached fallback, Webflow status page checks, communication templates, and postmortem process. Trigger with phrases like "webflow incident", "webflow outage", "webflow down", "webflow on-call", "webflow emergency", "webflow broken".
vercel-incident-runbook
Vercel incident response procedures with triage, instant rollback, and postmortem. Use when responding to Vercel-related outages, investigating production errors, or running post-incident reviews for deployment failures. Trigger with phrases like "vercel incident", "vercel outage", "vercel down", "vercel on-call", "vercel emergency", "vercel broken".
veeva-incident-runbook
Veeva Vault incident runbook for enterprise operations. Use when implementing advanced Veeva Vault patterns. Trigger: "veeva incident runbook".
vastai-incident-runbook
Execute Vast.ai incident response for GPU instance failures and outages. Use when responding to instance failures, investigating training crashes, or handling spot preemption emergencies. Trigger with phrases like "vastai incident", "vastai outage", "vastai down", "vastai emergency", "vastai instance failed".
twinmind-incident-runbook
Incident response for TwinMind failures: transcription not starting, audio not captured, sync failures, and calendar disconnect. Use when implementing incident runbook, or managing TwinMind meeting AI operations. Trigger with phrases like "twinmind incident runbook", "twinmind incident runbook".
supabase-incident-runbook
Execute Supabase incident response: dashboard health checks, connection pool status, pg_stat_activity queries, RLS debugging, Edge Function logs, storage health, and escalation. Use when responding to Supabase outages, investigating production errors, debugging connection issues, or preparing evidence for Supabase support escalation. Trigger: "supabase incident", "supabase outage", "supabase down", "supabase on-call", "supabase emergency", "supabase broken", "supabase connection issues".
speak-incident-runbook
Incident response for Speak API outages: triage, fallback to offline mode, and recovery procedures. Use when implementing incident runbook, or managing Speak language learning platform operations. Trigger with phrases like "speak incident runbook", "speak incident runbook".
snowflake-incident-runbook
Execute Snowflake incident response with triage, rollback, and postmortem using real SQL diagnostics. Use when responding to Snowflake outages, investigating query failures, or running post-incident reviews for pipeline failures. Trigger with phrases like "snowflake incident", "snowflake outage", "snowflake down", "snowflake on-call", "snowflake emergency".
shopify-incident-runbook
Execute Shopify incident response with triage using Shopify status page, API health checks, and rate limit diagnosis. Trigger with phrases like "shopify incident", "shopify outage", "shopify down", "shopify on-call", "shopify emergency", "shopify not responding".
sentry-incident-runbook
Execute incident response procedures using Sentry error monitoring. Use when investigating production outages, triaging error spikes, classifying incident severity, or building postmortem reports from Sentry data. Trigger with phrases like "sentry incident", "sentry triage", "investigate sentry error", "sentry runbook", "production incident sentry".