intercom-incident-runbook

name	intercom-incident-runbook
description	Execute Intercom incident response procedures with triage, mitigation, and postmortem. Use when responding to Intercom API outages, investigating integration errors, or running post-incident reviews for Intercom failures. Trigger with phrases like "intercom incident", "intercom outage", "intercom down", "intercom on-call", "intercom emergency", "intercom broken".
allowed-tools	Bash(curl:*), Bash(kubectl:*)
version	1.6.0
license	MIT
author	Jeremy Longshore <[e-mail]>
tags	["saas","support","messaging","intercom"]
compatibility	Designed for Claude Code

Intercom Incident Runbook

Overview

Rapid incident response procedures for Intercom integration failures. The runbook takes you from alert to resolution in four phases — triage, decision, mitigation, and postmortem — with HTTP-status-code-driven branching so you always know whether the fault is yours or Intercom's. High-level workflow lives here; the full copy-paste scripts and templates live in references/.

Prerequisites

• INTERCOM_ACCESS_TOKEN exported in your shell (a workspace admin token).
• curl and jq installed for API + status-page probing.
• kubectl access to the deployment running your Intercom integration (for restarts).
• Access to your secret manager (e.g. AWS Secrets Manager) to rotate a compromised token.
• Developer Hub access for the Intercom app, or a path to escalate to a workspace admin.

Severity Levels

Level	Definition	Response Time	Example
P1	All Intercom API calls failing	< 15 min	401 auth failures, API unreachable
P2	Degraded service	< 1 hour	High latency, rate limited (429)
P3	Partial impact	< 4 hours	Webhook delays, search timeouts
P4	No user impact	Next business day	Monitoring gaps, stale cache

Instructions

Work the phases in order. Each phase links to the full reference when you need depth.

1. Assign severity. Match the symptom to the table above; this sets your clock and who you page.

2. Triage — is it you or Intercom? Run the first probe to confirm reachability:

   curl -s -o /dev/null -w "%{http_code}" \
     -H "Authorization: Bearer $INTERCOM_ACCESS_TOKEN" \
     https://api.intercom.io/me
   

   Then check status.intercom.com for a platform incident and read the rate-limit headers. The full 5-step diagnostic script and the branch-by-branch decision tree are in references/triage.md.

3. If Intercom reports an incident, it is their problem — enable graceful degradation and monitor. If not, it is your integration; branch on the status code: 401 → rotate token, 403 → add OAuth scope, 429 → queue/backoff, 5xx → retry with backoff.