lindy-incident-runbook
Get diagnostic steps and severity guidelines for handling Lindy AI agent failures and platform outages.
Install
mkdir -p .claude/skills/lindy-incident-runbook && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4855" && unzip -o skill.zip -d .claude/skills/lindy-incident-runbook && rm skill.zipInstalls to .claude/skills/lindy-incident-runbook
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Incident response procedures for Lindy AI agent failures and outages.Key capabilities
- →Assess incident severity levels
- →Perform quick diagnostics on platform status
- →Execute fallback procedures for webhook failures
- →Re-authorize expired integration tokens
- →Generate post-incident reports
How it works
It defines a structured response process for service interruptions, including diagnostic steps for platform status, credit checks, and integration health.
Inputs & outputs
When to use lindy-incident-runbook
- →Diagnosing Lindy API downtime
- →Troubleshooting failing webhooks
- →Setting up on-call procedures
- →Assessing incident severity levels
About this skill
Lindy Incident Runbook
Overview
Incident response procedures for Lindy AI agent failures. Covers platform outages, individual agent failures, integration breakdowns, credit exhaustion, and webhook endpoint failures.
Incident Severity Levels
| Severity | Description | Response Time | Examples |
|---|---|---|---|
| SEV1 | All agents failing, customer impact | 15 minutes | Lindy platform outage, all webhooks failing |
| SEV2 | Critical agent down | 30 minutes | Support bot offline, phone agent unreachable |
| SEV3 | Degraded performance | 2 hours | High latency, intermittent failures |
| SEV4 | Minor issue | 24 hours | Non-critical agent misconfigured |
Quick Diagnostics (First 5 Minutes)
Step 1: Check Lindy Platform Status
# Is Lindy up?
curl -s -o /dev/null -w "Lindy API: HTTP %{http_code}\n" \
"https://public.lindy.ai" --max-time 5
# Check status page
echo "Status page: https://status.lindy.ai"
Step 2: Check Your Integration
# Is your webhook receiver up?
curl -s -o /dev/null -w "Our endpoint: HTTP %{http_code}\n" \
"https://api.yourapp.com/health" --max-time 5
# Is the webhook auth working?
curl -s -o /dev/null -w "Webhook auth: HTTP %{http_code}\n" \
-X POST "https://api.yourapp.com/lindy/callback" \
-H "Authorization: Bearer $LINDY_WEBHOOK_SECRET" \
-H "Content-Type: application/json" \
-d '{"test": true}' --max-time 5
Step 3: Check Credit Balance
Log in at > Settings > Billing
- Credits at 0? Agents stop processing
- Credits low? Non-essential agents may be paused
Incident Playbooks
Incident: Lindy Platform Outage (SEV1)
Symptoms: All agents failing, status.lindy.ai shows incident Impact: All Lindy-dependent workflows halted
Runbook:
- Confirm outage at https://status.lindy.ai
- Notify team: "Lindy platform outage confirmed. All agents affected."
- Activate fallback procedures:
- Route support emails to human inbox
- Disable webhook triggers from your app
- Queue events for replay when Lindy recovers
- Monitor status page for recovery
- When recovered: re-enable triggers, replay queued events, verify agent health
Fallback code:
async function triggerLindyWithFallback(payload: any) {
try {
const response = await fetch(WEBHOOK_URL, {
method: 'POST',
headers: {
'Authorization': `Bearer ${SECRET}`,
'Content-Type': 'application/json',
},
body: JSON.stringify(payload),
signal: AbortSignal.timeout(10000), // 10s timeout
});
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return { routed: 'lindy' };
} catch (error) {
console.error('Lindy unreachable, activating fallback:', error);
await queueForReplay(payload); // Store for later
await notifyTeam(`Lindy trigger failed: ${error}`);
return { routed: 'fallback' };
}
}
Incident: Individual Agent Failure (SEV2)
Symptoms: Specific agent tasks showing "Failed" status Impact: One workflow affected, others may be fine
Runbook:
- Open agent > Tasks tab > Filter by "Failed"
- Click latest failed task — identify the failing step
- Diagnose based on failing step type:
- Trigger step: Auth expired? Filter too restrictive?
- Action step: Integration token expired? Target API down?
- Condition step: Ambiguous condition prompt?
- Agent step: Looping? Exit conditions unreachable?
- Fix the root cause:
- Re-authorize expired integrations
- Fix action configuration
- Simplify condition prompts
- Add fallback exit conditions
- Test with a manual trigger
- Monitor next 5 tasks for success
Incident: Integration Auth Expired (SEV2-3)
Symptoms: Actions failing with "Not authorized" or "Token expired" Impact: All tasks using that integration fail
Runbook:
- Identify which integration is failing (Gmail, Slack, Sheets, etc.)
- In Lindy dashboard: Settings > Integrations
- Find the expired connection (may show warning icon)
- Click Re-authorize and complete OAuth flow
- Re-test the agent with a manual trigger
- Set calendar reminder for 90-day re-authorization check
Incident: Credit Exhaustion (SEV2-3)
Symptoms: Agents stop running, no new tasks created Impact: All agents paused until credits refill
Runbook:
- Confirm at Settings > Billing: credits at 0
- Immediate: Upgrade plan or purchase additional credits
- Investigate: Which agent consumed the most credits?
- Root cause: trigger storm? looping agent step? large model overuse?
- Fix: Add trigger filters, set exit conditions, downgrade model
- Prevent: Set budget alerts at 50%, 80%, 95% thresholds
Incident: Webhook Endpoint Failure (SEV2-3)
Symptoms: Lindy agent runs but your callback never receives data Impact: Agent completes but results are lost
Runbook:
- Check your endpoint health:
curl -s https://api.yourapp.com/health - Check server logs for incoming requests from Lindy
- Verify the HTTP Request action URL matches your production endpoint
- Test endpoint independently: send a POST with curl
- If endpoint was down: replay failed tasks (re-trigger the agent)
- If URL mismatch: update URL in Lindy agent HTTP Request action
Escalation Matrix
| Level | Contact | When |
|---|---|---|
| L1 | On-call engineer | Initial response, diagnostics |
| L2 | Engineering lead | After 30 min SEV1, 1 hour SEV2 |
| L3 | VP Engineering | After 1 hour SEV1 |
| Lindy Support | [email protected] | Confirmed Lindy platform issue |
Post-Incident Template
## Incident Report
**Date**: YYYY-MM-DD
**Severity**: SEV[1-4]
**Duration**: [start time] to [end time] ([total minutes])
**Impact**: [what was affected, customer impact]
### Timeline
- HH:MM — Issue detected via [monitoring/user report]
- HH:MM — On-call paged, diagnostics started
- HH:MM — Root cause identified: [cause]
- HH:MM — Fix applied: [what was done]
- HH:MM — Service restored, monitoring confirmed
### Root Cause
[Technical description of what failed and why]
### Resolution
[What was done to fix it]
### Prevention
- [ ] [Action item 1]
- [ ] [Action item 2]
- [ ] [Action item 3]
Error Handling
| Incident Type | Detection | Automated Response |
|---|---|---|
| Platform outage | Health check fails | Queue events, notify team |
| Agent failure | Task Completed trigger | Slack alert to #ops |
| Auth expiry | Action step fails | Alert + re-auth link |
| Credit exhaustion | Billing check | Pause non-critical agents |
| Endpoint down | Health check | Redirect to fallback |
Resources
- Lindy Status
- Lindy Support
- Lindy Community
Next Steps
Proceed to lindy-data-handling for data security and compliance.
When not to use it
- →When performing routine maintenance or non-emergency configuration changes
Prerequisites
Limitations
- →Requires manual trigger of fallback procedures
- →Severity assessment is subjective based on impact
How it compares
It provides a predefined escalation matrix and recovery playbook rather than relying on ad-hoc troubleshooting during an outage.
Compared to similar skills
lindy-incident-runbook side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| lindy-incident-runbook (this skill) | 1 | 27d | Review | Advanced |
| qa-tester | 29 | 9mo | No flags | Intermediate |
| analyzing-logs | 14 | 27d | Review | Beginner |
| home-assistant-manager | 9 | 8mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
qa-tester
svilupp
Browser automation QA testing skill. Systematically tests web applications for functionality, security, and usability issues. Reports findings by severity (CRITICAL/HIGH/MEDIUM/LOW) with immediate alerts for critical failures.
analyzing-logs
jeremylongshore
Analyze application logs to detect performance issues, identify error patterns, and improve stability by extracting key insights.
home-assistant-manager
komal-SkyNET
Expert-level Home Assistant configuration management with efficient deployment workflows (git and rapid scp iteration), remote CLI access via SSH and hass-cli, automation verification protocols, log analysis, reload vs restart optimization, and comprehensive Lovelace dashboard management for tablet-optimized UIs. Includes template patterns, card types, debugging strategies, and real-world examples.
distributed-tracing
wshobson
Implement distributed tracing with Jaeger and Tempo to track requests across microservices and identify performance bottlenecks. Use when debugging microservices, analyzing request flows, or implementing observability for distributed systems.
service-mesh-observability
wshobson
Implement comprehensive observability for service meshes including distributed tracing, metrics, and visualization. Use when setting up mesh monitoring, debugging latency issues, or implementing SLOs for service communication.
sentry
openai
Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.