posthog-incident-runbook
/posthog-incident-runbook
Wykonuje procedury reagowania na incydenty PostHog: triaż, łagodzenie skutków i postmortem, przy awariach, badaniu błędów i przeglądach po incydencie.
- Autor
- HelixDevelopment ↗
- Repozytorium
- agent ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 14.10.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 6
Brak sygnałów. Repozytorium zmienione 14.10.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Wykonuje procedury reagowania na incydenty PostHog: triaż, łagodzenie skutków i postmortem, przy awariach, badaniu błędów i przeglądach po incydencie.
Wyzwalacze z opisu
Oryginalny opis (EN)
Execute PostHog incident response procedures with triage, mitigation, and postmortem. Use when responding to PostHog-related outages, investigating errors, or running post-incident reviews for PostHog integration failures. Trigger with phrases like "posthog incident", "posthog outage", "posthog down", "posthog on-call", "posthog emergency", "posthog broken".
Jak działa
- Overview
- Prerequisites
- Severity Levels
- Quick Triage
- Decision Tree
- Immediate Actions by Error Type
- Communication Templates
- Post-Incident
- Instructions
- Output
Podgląd SKILL.md
---
name: posthog-incident-runbook
description: |
Execute PostHog incident response procedures with triage, mitigation, and postmortem.
Use when responding to PostHog-related outages, investigating errors,
or running post-incident reviews for PostHog integration failures.
Trigger with phrases like "posthog incident", "posthog outage",
"posthog down", "posthog on-call", "posthog emergency", "posthog broken".
allowed-tools: Read, Grep, Bash(kubectl:*), Bash(curl:*)
version: 1.0.0
license: MIT
author: Jeremy Longshore <jeremy@intentsolutions.io>
---
# PostHog Incident Runbook
## Overview
Rapid incident response procedures for PostHog-related outages.
## Prerequisites
- Access to PostHog dashboard and status page
- kubectl access to production cluster
- Prometheus/Grafana access
- Communication channels (Slack, PagerDuty)
## Severity Levels
| Level | Definition | Response Time | Examples |
|-------|------------|---------------|----------|
| P1 | Complete outage | < 15 min | PostHog API unreachable |
| P2 | Degraded service | < 1 hour | High latency, partial failures |
| P3 | Minor impact | < 4 hours | Webhook delays, non-critical errors |
| P4 | No user impact | Next business day | Monitoring gaps |
## Quick Triage
```bash
# 1. Check PostHog status
curl -s https://status.posthog.com | jq
# 2. Check our integration health
curl -s https://api.yourapp.com/health | jq '.services.posthog'
# 3. Check error rate (last 5 min)
curl -s localhost:9090/api/v1/query?query=rate(posthog_errors_total[5m])
# 4. Recent error logs
kubectl logs -l app=posthog-integration --since=5m | grep -i error | tail -20
```
## Decision Tree
```
PostHog API returning errors?
├─ YES: Is status.posthog.com showing incident?
│ ├─ YES → Wait for PostHog to resolve. Enable fallback.
│ └─ NO → Our integration issue. Check credentials, config.
└─ NO: Is our service healthy?
├─ YES → Likely resolved or intermittent. Monitor.
└─ NO → Our infrastructure issue. Check pods, memory, network.
```
## Immediate Actions by Error Type
### 401/403 - Authentication
```bash
# Verify API key is set
kubectl get secret posthog-secrets -o jsonpath='{.data.api-key}' | base64 -d
# Check if key was rotated
# → Verify in PostHog dashboard
# Remediation: Update secret and restart pods
kubectl create secret generic posthog-secrets --from-literal=api-key=NEW_KEY --dry-run=client -o yaml | kubectl apply -f -
kubectl rollout restart deployment/posthog-integration
```
### 429 - Rate Limited
```bash
# Check rate limit headers
curl -v https://api.posthog.com 2>&1 | grep -i rate
# Enable request queuing
kubectl set env deployment/posthog-integration RATE_LIMIT_MODE=queue
# Long-term: Contact PostHog for limit increase
```
### 500/503 - PostHog Errors
```bash
# Enable graceful degradation
kubectl set env deployment/posthog-integration POSTHOG_FALLBACK=true
# Notify users of degraded service
# Update status page
# Monitor PostHog status for resolution
```
## Communication Templates
### Internal (Slack)
```
🔴 P1 INCIDENT: PostHog Integration
Status: INVESTIGATING
Impact: [Describe user impact]
Current action: [What you're doing]
Next update: [Time]
Incident commander: @[name]
```
### External (Status Page)
```
PostHog Integration Issue
We're experiencing issues with our PostHog integration.
Some users may experience [specific impact].
We're actively investigating and will provide updates.
Last updated: [timestamp]
```
## Post-Incident
### Evidence Collection
```bash
# Generate debug bundle
./scripts/posthog-debug-bundle.sh
# Export relevant logs
kubectl logs -l app=posthog-integration --since=1h > incident-logs.txt
# Capture metrics
curl "localhost:9090/api/v1/query_range?query=posthog_errors_total&start=2h" > metrics.json
```
### Postmortem Template
```markdown
## Incident: PostHog [Error Type]
**Date:** YYYY-MM-DD
**Duration:** X hours Y minutes
**Severity:** P[1-4]
### Summary
[1-2 sentence description]
### Timeline
- HH:MM - [Event]
- HH:MM - [Event]
### Root Cause
[Technical explanation]
### Impact
- Users affected: N
- Revenue impact: $X
### Action Items
- [ ] [Preventive measure] - Owner - Due date
```
## Instructions
### Step 1: Quick Triage
Run the triage commands to identify the issue source.
### Step 2: Follow Decision Tree
Determine if the issue is PostHog-side or internal.
### Step 3: Execute Immediate Actions
Apply the appropriate remediation for the error type.
### Step 4: Communicate Status
Update internal and external stakeholders.
## Output
- Issue identified and categorized
- Remediation applied
- Stakeholders notified
- Evidence collected for postmortem
## Error Handling
| Issue | Cause | Solution |
|-------|-------|----------|
| Can't reach status page | Network issue | Use mobile or VPN |
| kubectl fails | Auth expired | Re-authenticate |
| Metrics unavailable | Prometheus down | Check backup metrics |
| Secret rotation fails | Permission denied | Escalate to admin |
## Examples
### One-Line Health Check
```bash
curl -sf https://api.yourapp.com/health | jq '.services.posthog.status' || echo "UNHEALTHY"
```
## Resources
- [PostHog Status Page](https://status.posthog.com)
- [PostHog Support](https://support.posthog.com)
## Next Steps
For data handling, see `posthog-data-handling`.
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · HelixDevelopment/agent | 100 | MIT |
| jeremylongshore/tons-of-skills-marketplace | 100 | MIT |
Migawka bazy z 28.10.2026 · wersja paczki 2f9307a5cf19 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100vastai-incident-runbook
Prowadzi procedury reagowania na incydenty Vast.ai: triaż, łagodzenie i postmortem przy awariach, badaniu błędów i przeglądach po incydencie. - 100replit-incident-runbook
Prowadzi procedury reagowania na incydenty Replit: triage, łagodzenie skutków i postmortem, przy awariach, błędach i przeglądach po incydencie. - 100lokalise-incident-runbook
Prowadzi reagowanie na incydenty związane z Lokalise: segregacja, łagodzenie skutków i postmortem, przy awariach, badaniu błędów i przeglądach po incydentach integracji. - 100klaviyo-incident-runbook
Prowadzi przez reagowanie na incydenty związane z Klaviyo: triage, łagodzenie skutków i postmortem, także przy błędach API 401, 403, 429 i 5xx w dyżurze on-call. - 90incident-runbook
Prowadzi reakcję na incydent od diagnozy przez łagodzenie do rozwiązania, potem postmortem bez szukania winnych i powtarzalny runbook, gdy produkcja jest zdegradowana lub awarie wracają. - 100hatch3r-incident-response
Obsługuje incydenty produkcyjne ze strukturalnym triażem, łagodzeniem skutków i post-mortem, także przy awariach i incydentach bezpieczeństwa.