Observability für kleine SaaS-Teams: Der minimale Stack in 2026

Eine zweiköpfige On-Call-Rotation bei einem Seed-Stage-SaaS braucht nicht dieselbe Observability-Plattform wie ein 200-Mann-Enterprise. Sie muss aber echte Incidents abfangen, bevor es die Kunden tun. Diese beiden Dinge sind nicht dasselbe, und Preismodelle, die jedes Feature in eine einzige Pro-Host-pro-Monat-Position bündeln, haben zu viele Early-Stage-Teams dazu gebracht, Enterprise-Preise für Startup-Sichtbarkeit zu zahlen. Observability für kleine SaaS-Teams in 2026 bedeutet, diese Lücke zu schließen: die Signale bekommen, die wichtig sind, zu Kosten, die das Infrastrukturbudget nicht dominieren, mit Alert-Policies, die die Menschen am Pager nicht ausbrennen.

Dieser Beitrag behandelt den minimalen Observability-Stack für ein kleines SaaS-Team - typischerweise zwei bis acht Entwickler, eine Handvoll Services und eine monatliche Infrastrukturrechnung, die die Gründer noch in einer Tabellenkalkulation sehen. Die Tooling-Entscheidungen sind praktisch und Open-Source-zuerst. Die Architektur ist so gestaltet, dass jede Komponente ersetzt werden kann, wenn das Team wächst, ohne die bereits geleistete Instrumentierungsarbeit wegzuwerfen.

Warum die Standardoptionen nicht mehr passen

Vor einigen Jahren war das Greifen nach Datadog oder New Relic ein offensichtlicher Ausgangspunkt für ein finanziertes Startup. Die DX war gut, die Integrationen waren zahlreich und die Kosten bei einigen wenigen Hosts fühlten sich überschaubar an. Was sich geändert hat, ist die Preistrajektorie im Maßstab. Datadogs host-basierte Abrechnung bedeutet, dass das Hinzufügen von Services - selbst kleiner - die Rechnung jedes Quartal merklich erhöht. Teams, die von vier auf zwölf Services über zwei Jahre gewachsen sind, stellten fest, dass sich ihre Observability-Kosten um den Faktor drei oder vier multipliziert hatten, während die Sichtbarkeit, die sie tatsächlich täglich nutzten, ungefähr gleich blieb.

New Relics Pro-Nutzer- und Pro-Daten-Einnahmen-Modelle erzeugen eine andere Version desselben Problems. In dem Moment, in dem man anfängt, Logs in nennenswertem Volumen aufzubewahren, klettern die Zahlen schnell.

Für ein kleines SaaS-Team ist der Kostendruck nicht, weil die absolute Zahl katastrophal ist, sondern weil jeder Euro in der Burn-Rate unter der Lupe liegt, und eine vierstellige monatliche Observability-Rechnung ist schwer gegenüber einem Vorstand zu rechtfertigen, wenn der äquivalente Open-Source-Stack den Preis einer kleinen VM kostet.

Die Open-Source-Alternative ist kein Kompromiss. OpenTelemetry ist jetzt der herstellerneutrale Standard für Instrumentierung, und die Backends, die es konsumieren - Grafana, Loki, Tempo, Prometheus - sind produktionsreif, gut dokumentiert und weit verbreitet. Der Hauptaufwand ist operativ: du besitzt die Infrastruktur und die Konfiguration. Für ein Team mit auch nur einem Entwickler, der Zeit in der Observability-Schicht verbracht hat, ist das ein akzeptabler Kompromiss.

Der minimale Stack mit vier Komponenten

Der minimale Observability-Stack für ein kleines SaaS-Team hat vier Teile, die den Kern-Observability-Signalen entsprechen.

Metriken: Prometheus und Grafana. Prometheus scrapt Metriken von deinen Anwendungsendpunkten und deiner Infrastruktur. Grafana rendert sie in Dashboards und wertet Alert-Regeln aus. Diese Kombination ist so Standard, dass fast jede Open-Source-Bibliothek und jedes Framework bereits einen /metrics-Endpunkt bereitstellt, den Prometheus versteht. Du wirst fast keine Zeit damit verbringen, benutzerdefinierte Instrumentierung für die Grundlagen zu schreiben - Request-Raten, Latenz-Histogramme, Fehlerzählungen, Queue-Tiefen. Konfigurationszeit wird in Stunden gemessen, nicht Tagen, für eine Standardanwendung. Das Betreiben beider auf einer einzigen Hetzner- oder Scaleway-VM beginnt bei ca. 5-15 Euro pro Monat.

Logs: Grafana Loki. Loki ist ein horizontal skalierbares Log-Aggregationssystem, das Labels statt vollständiger Log-Inhalte indexiert. Das macht es deutlich günstiger zu betreiben als Elasticsearch-basierte Stacks bei jedem nennenswerten Log-Volumen. Ein Team, das strukturierte JSON-Logs aus seiner Anwendung liefert, erhält Per-Request-Kontext, Korrelations-IDs, Fehlerklassifizierung und nutzerbegrenztes Debugging - alles über LogQL abfragbar. Die kritische Voraussetzung ist strukturiertes Logging von Anfang an. Eine Anwendung, die unstrukturierten Klartext-Logs an Loki liefert, wird viel schwieriger zu handhaben sein als eine, die konsistentes JSON mit Feldern wie trace_id, user_id, service und level ausgibt.

Traces: OpenTelemetry SDK und Tempo. OpenTelemetry bietet sprachspezifische SDKs, die deine Anwendung mit verteilten Traces instrumentieren. Jede eingehende Anfrage erhält eine Trace-ID, die durch jeden Service-Aufruf, jede Datenbankabfrage und jede externe API-Anfrage in der Kette propagiert wird. Tempo ist ein kosteneffizienter Trace-Backend von Grafana Labs, der Traces object-store-first speichert (kompatibel mit S3 oder MinIO) und sie per Trace-ID abfragt. Er integriert direkt in Grafana, sodass ein langsamer Span in einem Trace mit den Log-Zeilen und den Metriken korreliert werden kann, die im gleichen Moment aufgezeichnet wurden. Diese Korrelation - vom Trace auf die genaue Log-Zeile klicken, die während des langsamen Spans ausgelöst wurde - ist das, was rohe Telemetriedaten in echte Observability verwandelt.

Alerting: AlertManager mit einem bewusst kleinen Regelwerk. Prometheus AlertManager übernimmt Routing und Deduplizierung. Das Regelwerk sollte bewusst klein sein. Ein kleines SaaS-Team ist wahrscheinlicher durch Alert-Müdigkeit geschädigt - wo ein müder On-Call-Entwickler anfängt, Pages zu ignorieren, weil zu viele davon Lärm sind - als durch zu wenige Alerts. Beginne mit vier oder fünf Regeln: Service-Level-Fehlerrate über Schwellenwert, p99-Latenz überschreitet SLO-Budget, Queue wächst über ein Rückstandslimit, Festplattennutzung über 80% und ein fehlgeschlagener Health-Check. Füge neue Regeln nur hinzu, wenn ein echter Incident zeigt, dass eine bestehende Lücke von einer Frühwarnung profitiert hätte.

Strukturiertes Logging ist das nicht-verhandelbare Fundament

Jeder andere Teil des Stacks wird viel schwieriger, wenn die Anwendung keine strukturierten Logs ausgibt. Strukturiertes Logging bedeutet, dass jede Log-Zeile ein JSON-Objekt mit einem konsistenten Schema ist: ein Zeitstempel, ein Severity-Level, ein Service-Name, eine Trace-ID, eine Nachricht und welche Domain-spezifischen Felder auch immer für das Event relevant sind. Das ist die Voraussetzung für Loki-Label-Queries, für das Korrelieren einer Log-Zeile mit ihrem übergeordneten Trace und für das Erstellen bedeutungsvoller Dashboards aus log-abgeleiteten Metriken.

Ein häufiges Fehlermuster sind Teams, die für Entwickler lesbare Konsolen-Logs in die Produktion liefern - Zeilen, die im Terminal leicht zu lesen, aber bei Skalierung unmöglich abzufragen sind. Der Fix ist nicht komplex, erfordert aber früh bewusstes Setup. Die meisten Logging-Frameworks unterstützen strukturierte Ausgabe mit minimalem Konfigurationsaufwand.

Das Trace-ID-Feld verdient besondere Aufmerksamkeit. Jede eingehende HTTP-Anfrage, jeder gereihte Job und jeder Hintergrundworker-Aufruf sollte vom Moment seines Eintritts in das System eine eindeutige Trace-ID tragen. Diese ID sollte an jede Log-Zeile angehängt werden, die während des Lebenszyklus dieser Anfrage ausgegeben wird. Wenn etwas schief geht, wird die Trace-ID zum Faden, der jede Log-Zeile, jeden nachgelagerten Aufruf und jede Datenbankabfrage zusammenzieht, die diesen bestimmten Arbeitsabschnitt berührt hat. Ohne sie wird das Debuggen von Incidents bei jeder Skalierung zu einer zeitaufwendigen Übung in Log-Archäologie.

Für Teams, die ihre allgemeine Code-Qualität und Logging-Praktiken verbessern möchten, zahlt sich die Investition in strukturiertes Logging typischerweise schnell in reduzierter Incident-Auflösungszeit zurück.

SLO-Disziplin für kleine Teams

Service Level Objectives werden oft als eine Praxis für Unternehmen angesehen, die groß genug für dedizierte Reliability-Engineers sind. Sie sind tatsächlich nützlicher für kleine Teams, weil sie subjektive Argumente über Systemgesundheit durch ein gemeinsames, objektives Maß ersetzen.

Ein SLO für ein kleines SaaS-Produkt muss nicht kompliziert sein. Definiere Verfügbarkeit als Prozentsatz der Anfragen, die mit einem 2xx- oder 3xx-Statuscode abschließen. Setze ein monatliches Ziel - 98,5% oder 99% ist ein vernünftiger Ausgangspunkt für die meisten SaaS-Anwendungen, die keine medizinischen oder finanziellen Transaktionen verarbeiten. Leite ein Fehlerbudget aus diesem Ziel ab: ein monatliches SLO von 99% gibt dir etwa 7 Stunden und 18 Minuten zulässige Ausfallzeit pro Monat.

Das Fehlerbudget macht zwei Dinge. Es zeigt dir, wenn du Kapazität hast, Deployment-Risiken einzugehen - wenn du bis Monatsmitte nur 10% deines Budgets verbraucht hast, war das System stabil und du kannst aggressiv liefern. Es zeigt dir, wann du langsamer werden solltest - wenn du in den ersten zwei Wochen 80% deines Budgets verbrannt hast, ist die richtige Reaktion, nicht-kritische Deployments einzufrieren und dich auf Zuverlässigkeit zu konzentrieren. Diese Disziplin ist es, die eine kleine On-Call-Rotation über die Zeit gesund hält, weil sie die vage Angst "ist das System gesund?" durch eine konkrete Zahl ersetzt, die jeder sehen kann.

Prometheus AlertManager kann die Fehlerbudget-Burn-Rate direkt auswerten. Ein Burn-Rate-Alert wird nicht ausgelöst, wenn die Fehlerrate einen Schwellenwert überschreitet, sondern wenn die aktuelle Rate des Budgetverbrauchs das monatliche Budget schneller erschöpfen würde, als das SLO erlaubt. Das ist ein viel nützlicheres Signal für kleine Teams als ein einfacher Schwellenwert-Alert, weil es früh genug auslöst, um zu handeln und nicht so häufig, dass es zu Hintergrundrauschen wird.

Deployment: Eine VM oder eine leichte Managed-Option

Der hier beschriebene Observability-Stack kann komfortabel auf einer einzelnen Hetzner CX21- oder Scaleway DEV1-S-Instanz im Bereich von 5-10 Euro pro Monat laufen, insbesondere für ein kleines SaaS-Team, das bescheidene Log- und Metrikvolumina generiert. Grafana, Prometheus, Loki und Tempo sind alle leichtgewichtige Prozesse. Die Hauptressource, auf die man achten muss, ist die Festplatte, die mit Log- und Trace-Aufbewahrung wächst. Eine 40GB-Festplatte ist ein vernünftiger Ausgangspunkt mit 7-Tage-Aufbewahrung.

Für Teams, die überhaupt keine selbst gehostete Infrastruktur betreiben möchten, bietet Grafana Cloud ein großzügiges kostenloses Kontingent: 50GB Logs, 10.000 Metrik-Serien und 50GB Traces pro Monat. Das deckt die meisten kleinen SaaS-Produkte durch ihre frühe Wachstumsphase bei Nullkosten ab. Die Instrumentierung, die du gegen das OpenTelemetry SDK schreibst, exportiert zu Grafana Cloud oder zu deiner eigenen Tempo-Instanz ohne Änderungen am Anwendungscode. Diese Portabilität ist einer der konkreten Vorteile des Bauens auf offenen Standards von Anfang an.

Teil einer guten Tech-Stack-Strategie ist das Treffen von Entscheidungen, die Optionen offen lassen, wenn das Team wächst. Ein auf OpenTelemetry und Grafana basierender Observability-Stack tut genau das: er kann selbst gehostet zu minimalen Kosten laufen, zu einem Managed-Tier migrieren wenn das Volumen wächst oder zu einem kommerziellen Backend exportieren, wenn das Team schließlich entscheidet, dass die operativen Einsparungen den höheren Aufwand wert sind.

Was am Anfang übersprungen werden sollte

Ein kleines SaaS-Team braucht keine zentralisierte Log-Pipeline mit Kafka oder Fluentd zwischen Anwendung und Loki. Es braucht keine Service-Mesh-Telemetrie bevor es mehr als fünf Services hat. Es braucht kein Multi-Region Prometheus-Federation bevor es eine Multi-Region-Anwendung hat. Und es braucht fast sicherlich nicht gleichzeitig Real-User-Monitoring, Synthetic-Monitoring, Continuous-Profiling und benutzerdefinierte Business-Metrics-Dashboards von Tag eins an.

Der minimale Observability-Stack ist minimal by Design. Das Ziel ist, ihn zu deployen, die Anwendung darauf zu richten und die nächsten Monate damit zu verbringen, herauszufinden, welche Signale in den Incidents, auf die man trifft, tatsächlich nützlich sind. Dieses Lernen ist es, das einem ermöglicht, den Stack intelligent zu erweitern statt Komplexität hinzuzufügen, weil ein Engineering-Blog-Beitrag sagte, man sollte es tun.

Auf Produktion kommen

Der schnellste Weg zu einem laufenden Stack ist eine docker-compose-Datei, die Prometheus, Grafana, Loki und Tempo zusammen mit vorkonfigurierten Datasources und Dashboards hochfährt. Die Grafana-Community pflegt eine Reihe von Starter-Dashboards für gängige Frameworks, die eine vernünftige Abdeckung ohne das Schreiben von PromQL geben. Instrumentiere deine Anwendung zunächst mit dem OpenTelemetry SDK im Auto-Instrumentierungsmodus - das gibt dir Traces und grundlegende Metriken mit fast keinen Code-Änderungen - und schichte manuelle Instrumentierung für die Spans und Events auf, die für deine Domain wichtig sind.

Innerhalb eines Tages fokussierter Setup-Arbeit kann ein kleines SaaS-Team die vier Komponenten laufend haben, Logs und Traces aus der Anwendung fließen lassen und ein grundlegendes SLO-Dashboard mit Fehlerrate und Latenz-Perzentilen haben. Dieses Fundament ist in echten Incidents mehr wert als eine sechsmonatige SaaS-Lizenz für eine Plattform, die jedes Quartal mehr kostet.

Wenn dein Team Observability von Grund auf einrichtet, von einer Plattform migriert, deren Kosten außer Verhältnis gewachsen sind, oder an einer umfassenderen Frage der Web-Anwendungsarchitektur arbeitet, sprechen wir gerne über die Einzelheiten. Melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io, um zu sehen, wie wir arbeiten.