| 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 <jeremy@intentsolutions.io> |
| tags | ["saas","evernote","incident-response"] |
| compatibility | Designed for Claude Code |
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.
curl -sf https://status.evernote.com/api/v2/status.json | jq '.status'
curl -sf -H "Authorization: Bearer $EVERNOTE_TOKEN" \
https://www.evernote.com/shard/s1/notestore | head -20
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.
