evernote-incident-runbook

name	evernote-incident-runbook
description	Manage incident response for Evernote integration issues. Use when troubleshooting production incidents, handling outages, or responding to Evernote service issues. Trigger with phrases like "evernote incident", "evernote outage", "evernote emergency", "troubleshoot evernote production".
allowed-tools	Read, Write, Edit, Bash(curl:*), Grep
version	1.13.0
license	MIT
author	Jeremy Longshore <[e-mail]>
tags	["saas","evernote","incident-response"]
compatibility	Designed for Claude Code, also compatible with Codex and OpenClaw

Evernote Incident Runbook

Overview

Step-by-step procedures for responding to Evernote integration incidents including API outages, rate limit escalations, authentication failures, data sync issues, and quota exhaustion.

Prerequisites

• Access to monitoring dashboards and production logs
• Production Evernote API credentials
• Communication channels for escalation (Slack, PagerDuty)

Instructions

Incident Classification

Severity	Symptoms	Response Time
P1 - Critical	All Evernote API calls failing, data loss risk	15 minutes
P2 - High	Persistent rate limits, auth failures for multiple users	1 hour
P3 - Medium	Intermittent errors, degraded sync performance	4 hours
P4 - Low	Single user issues, non-critical feature affected	Next business day

Step 1: Triage

Check Evernote's status page first. If Evernote is down, activate the circuit breaker and wait.

# Check Evernote service status
curl -sf https://status.evernote.com/api/v2/status.json | jq '.status'

# Check your API connectivity
curl -sf -H "Authorization: Bearer $EVERNOTE_TOKEN" \
  https://www.evernote.com/shard/s1/notestore | head -20

# Check error rate in logs (last 15 min)
grep -c 'EDAMSystemException' /var/log/evernote-app.log

Step 2: Rate Limit Escalation

If rate limits are persistent: reduce API call frequency, increase delays between batch operations, and contact Evernote developer support for a rate limit increase.

Step 3: Authentication Failure

For auth failures: verify tokens are not expired (edam_expires), check that production credentials match the production endpoint (sandbox: false), and test with a fresh Developer Token to isolate the issue.

Step 4: Sync Failure Recovery

For sync issues: compare local USN with server USN via getSyncState(). If gap is too large, reset to full sync from USN 0. Verify data integrity after re-sync.