Skip to content

Incident history

We publicly document all incidents with customer impact or compliance/privacy relevance, including severity, duration and concrete follow-up actions. No sugar-coated postmortems.

Severity scale

  • P0 — full platform outage, risk of data loss, compliance breach.
  • P1 — major feature unavailable, workaround available.
  • P2 — individual feature degraded, no customer impact.
  • P3 — cosmetic or internal tooling impacted.

Documented incidents

P1 Duration: 21h Surface: posthog

PostHog crash loop due to multi-microservice architecture pivot

Was ist passiert

Beim Versuch, PostHog Self-Hosted (Single-Node-Layout posthog/posthog:latest)

auf ins015222 zu starten, crasht der Web-Container in einer Endlos-Loop. Hintergrund:

PostHog hat 2026 die Architektur von Single-Node-Hobby zu Multi-Microservice

(Kafka/Redpanda + Capture-Services + neuere DB-Versionen) umgestellt — das alte

Compose-Layout ist mit latest inkompatibel.

Auswirkung auf Kunden

Keine kundensichtbare Auswirkung — PostHog ist ein internes Analytics-Werkzeug,

keine produktive Funktion. Plausible (cookieless) hat die Telemetrie parallel

übernommen, Live-Daten gingen nicht verloren.

Lessons Learned

  • Bei OSS-Selfhost-Stacks latest-Tag vermeiden, immer auf gepinnte Major-Version.
  • Microservice-Migrationen brauchen Backplane (Kafka) — kein Drop-in-Replacement

für Single-Node.

  • Plausible als cookieloser Fallback bewährt sich (kein Consent nötig).

Folge-Aktionen

  • PR #5: Plausible als Primary-Frontend-Analytics, PostHog optional via Flag.
  • PR #849: Dokumentation des Microservice-Pivots und der Alternativ-Routen

(Multi-Microservice / Plausible / Umami).

Resolution: PR #5 (Plausible-Switch) + PR #849 (Microservice-Pivot-Doku)

Source files (Markdown with YAML front-matter) live under /status/incidents/ in the public Git repository of the marketing site.