Agent skill · marketing growth · jeremylongshore
firecrawl-incident-runbook
Analyze and mitigate Firecrawl integration incidents involving outage, credits, throttling, policy denial, job failure, webhook loss, or unsafe content. Use when responding to active production impact. Trigger with "Firecrawl incident", "Firecrawl outage", or "Firecrawl crawl failure".
Why this skill is useful
Adds executable scripts for incident response and triage specific to Firecrawl integration issues that aren't publicly documented.
What it needs
Requires curl, jq installed locally. Requires firecrawl account access. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Firecrawl Incident Response Overview Stabilize the affected workflow, preserve privacy-safe evidence, and restore service through a tested degraded mode or rollback. Separate Firecrawl service health, target-origin behavior, and internal pipeline failures. Prerequisites The target repository or integration path and the requested operator outcome. The source authorization, data classification, and environment policy. Current Firecrawl documentation, credentials only when needed, and an owner for approvals. Current Contract Firecrawl's error catalog defines retryability; async operations expose job/status/cancellation surfaces; queue status helps distinguish capacity pressure; status polling remains the recovery path when webhooks are delayed or exhausted. A crawl webhook set does not include a crawl.failed event in the current documented event list. Authentication For authenticated Cloud operations, inject FIRECRAWLAPIKEY from an approved secret manager. REST requests use Authorization: Bearer with the key. Never print, commit, transmit, or place a key in a URL. Keyless access is suitable only where the current documentation explicitly allows it and the workload accepts its limits; production workflows should make identity and team ownership explicit. Instructions 1. Declare incident owner, severity, affected operation/environment, start time, customer impact, data risk, approved communication channel, and next update time. 2. Pause or bound producers before investigating if retries, crawl scope, or pay-as-you-go could amplify cost or target load. 3. Check internal deployments and dependencies, Firecrawl service evidence, credentials, credits, team restrictions, queue/concurrency, job state, webhook delivery, and target-origin status. 4. Classify the failure with the official error catalog. Retry only documented retryable classes, honor Retry-After, and cap attempts. 5. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/firecrawl-incident-runbook