Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich betreibe Observability für 12+ Produktions-SaaS-Apps auf Cloudflare Workers – mit einem Stack, der mich bei meinen Betriebsvolumina monatlich etwa 0 $ an Kosten für Monitoring durch Drittanbieter gekostet hat. Das bedeutet auch, dass ich jeden Fehlermodus im Monitoring erlebt habe: Ein Alert, der mich um 3 Uhr nachts pagingte, weil ein einzelner Canary-Deployment eine 5xx-Baseline ausgelöst hatte; ein fehlender Trace, der mich während eines D1 Write-Contention-Incidents zwei Tage gekostet hat; und eine RUM-Samplerate, die bei einem Tenant mit wenig Traffic so aggressiv war, dass ich keine Schlüsse daraus ziehen konnte. Jede Schwelle, Abfrage und Konfiguration unten ist eine, die ich selbst einsetze. TanStack Ship ist mein kostenpflichtiges Produkt; die Voreingenommenheit wird von Anfang an benannt.
Verifizierte Quellen: Cloudflare Workers Analytics Engine · Cloudflare Workers Observability · Web Vitals · OpenTelemetry · Google SRE Workbook — SLO chapter · TanStack Ship GitHub
Letztes Update: 2026-07-05 · Changelog
TL;DR: Performance-Monitoring und Observability sind nicht dasselbe. Monitoring sagt Ihnen, dass etwas nicht stimmt; Observability ermöglicht es Ihnen, herauszufinden, warum – ohne neuen Code auszuliefern. Für ein SaaS auf Cloudflare Workers im Jahr 2026 besteht der praktische Stack aus RUM für clientseitige Web Vitals, Workers Analytics Engine für Backend-Metriken und strukturierte Logs, Tail Workers für Distributed Tracing und Synthetic Checks für die Routen, die niemals ausfallen dürfen. Das Ganze wird mit SLIs und SLOs ummantelt, damit Alerts bei nutzersichtbarer Verschlechterung feuern – nicht bei Rauschen. Dieser Leitfaden konsolidiert die drei Säulen, RUM, Synthetics, Alerting, SLO-Mathematik und Kostenökonomie in einem Artikel – dem Artikel, den ich gebraucht hätte, als ich als Solo-Entwickler begann, produktionsreif im großen Maßstab zu operieren.
Monitoring vs. Observability: Die entscheidende Unterscheidung
Diese beiden Begriffe werden häufig synonym verwendet – und genau diese Verwechslung ist die Ursache für die meisten Monitoring-Stacks, die Sie aus den falschen Gründen pingen.
Was Monitoring tatsächlich leistet
Ein Monitor beantwortet eine Ja/Nein-Frage zu einem bestimmten Zeitpunkt: Liegt die 5xx-Rate über 1 %? Liegt die p95-Latenz über 800 ms? Liegt die Warteschlangentiefe über 10.000? Er basiert auf Metriken – Countern, Gauges, Histogrammen, die vorab aggregiert werden. Monitore sind günstig in der Auswertung und bilden die Grundlage für Alerts. Sie sind jedoch nicht das Werkzeug zum Debugging.
Wenn ein Monitor auslöst, lautet die nächste Frage: Warum hat sich diese Metrik verändert? Das erfordert die zweite Klasse von Telemetrie – hochkardinale Logs, Traces, Rohereignisse –, die sich nicht vorab aggregieren lassen, weil noch nicht bekannt ist, welche Dimensionen relevant sind. Das ist Observability.
In jeder TanStack-Ship-App, die ich betreibe, ist die Trennung klar. Workers Analytics Engine speichert die aggregierten Metriken, die Monitore und Dashboards antreiben – Request-Zählungen nach Route, Statusklasse, Latenzperzentile, D1-Abfragedauer. Das System ist günstig, schnell abfragbar und bewahrt die Daten 90 Tage lang auf. Dahinter liegen Workers Logs und Tail Workers mit den unstrukturierten Details: vollständige Request-Logs mit redigierten Headern, Konsolenausgabe, Exception-Traces, gesampelte Span-Trees.
Warum diese Unterscheidung beeinflusst, was Sie kaufen
Datadog, Honeycomb und New Relic verkaufen Observability-Plattformen und ergänzen Monitoring. Cloudflare-native Stacks verkaufen Monitoring und ergänzen Observability über Workers Logs und Tail Workers. Beide Ansätze gelangen zum selben Ziel, doch die Kostenkurven unterscheiden sich. Datadog berechnet Gebühren pro erfasstem Event und pro indiziertem Span; der Workers-native Stack berechnet Gebühren pro Analytics-Engine-Write zuzüglich des enthaltenen Workers-Logs-Kontingents. Bei Apps mit niedrigem bis mittlerem Volumen ist der zweite Ansatz deutlich günstiger. Bei hohem Volumen nähern sich die Kosten einander an. Auf die konkrete Kostenrechnung gehe ich später ein.
Die drei Säulen – implementiert für Edge SaaS
Logs, Metriken und Traces bilden die Standard-Taxonomie. Für eine Edge-Runtime ändert sich, wo sich jede Säule befindet und wie sie abgefragt wird.
Logs: strukturiert, request-scoped, gesampelt
Jeder Request erzeugt bei Abschluss eine einzelne Log-Zeile mit stabilem Format, einer Request-ID, einer Tenant-ID, der Route, dem Status, der Dauer und eventuellen Fehlermetadaten. Ich schreibe sie über console.log in Workers Logs – das Standardziel, das bei Workers Paid ohne Zusatzkosten für das erste Volumenkontingent enthalten ist.
// src/lib/logger.ts
export interface LogEntry {
ts: string;
level: "debug" | "info" | "warn" | "error";
requestId: string;
route: string;
status: number;
durationMs: number;
tenantId?: string;
userId?: string;
error?: { name: string; message: string; stack?: string };
}
export function logRequest(req: Request, ctx: ExecutionContext, entry: LogEntry) {
// Strukturiertes Einzeiler-JSON an Workers Logs (und via Tail Worker weitergeleitet, falls konfiguriert)
console.log(JSON.stringify(entry));
}
Zwei Regeln bewahren Sie davor, in Daten zu ertrinken. Erstens: Redigieren Sie an der Quelle – entfernen Sie Authorization, Cookie und alle Felder, die password|secret|token entsprechen, bevor Sie schreiben. Tail Workers können erneut redigieren, aber je weiter downstream Sie redigieren, desto mehr Stellen müssen Sie korrigieren. Zweitens: Samplen Sie die Debug-Ebene aggressiv (1 von 1.000) und lassen Sie info/warn/error unsampled. Das Signal-Rausch-Verhältnis Ihrer Incident-Suche wird von dieser Disziplin von Tag eins an festgelegt.
Metriken: Workers Analytics Engine als günstiges Herzstück
Workers Analytics Engine ist eine Zeitreihendatenbank mit SQL-Zugriff, abgerechnet pro geschriebenem Datenpunkt und pro Abfrage. Für ein SaaS in meinem Maßstab ist es die richtige Standardwahl. Das Format, das ich nutze, ist ein Dataset pro abgegrenztem Kontext – http_requests, db_queries, queue_jobs, business_events –, jedes mit einem kleinen festen Satz indizierter Dimensionen und einigen numerischen Blobs.
// src/lib/metrics.ts
export interface AnalyticsEnv {
HTTP_METRICS: AnalyticsEngineDataset;
}
export function recordRequest(env: AnalyticsEnv, data: {
route: string;
status: number;
durationMs: number;
tenantTier: "free" | "pro" | "enterprise";
}) {
env.HTTP_METRICS.writeDataPoint({
indexes: [data.route, String(Math.floor(data.status / 100) * 100), data.tenantTier],
doubles: [data.durationMs],
blobs: [],
});
}
Das Muster, das mir immer wieder geholfen hat, ist die Kardinalität der indexes bei etwa 200 pro Dataset zu halten. Route + Statusklasse + Tenant-Tier funktioniert. userId als Index hinzuzufügen ist ein Fehler – innerhalb einer Woche haben Sie 50.000 eindeutige Indizes und jede Abfrage fächert darüber auf. Hochkardinale Felder gehören in blobs (nicht indiziert) oder in Logs, niemals in indizierte Dimensionen.
Traces: Tail Workers für die langsamen Pfade
Für ein SaaS, in dem 95 % der Requests schnelles CRUD sind, ist vollständiges Distributed Tracing Overkill. Was ich tatsächlich brauche, ist ein kausaler Trace für die langsamen 5 %: der Checkout, der Webhook-Fan-Out, die Berichtsgenerierung. Tail Workers sind die richtige Primitive – sie fangen jede Log-Zeile eines Workers ab, hängen Timing-Daten an und leiten sie an ein Ziel weiter.
Deklarieren Sie einen Tail Worker in wrangler.jsonc, lassen Sie ihn jede console.log-Zeile parsen, gruppieren Sie sie nach Request-ID, berechnen Sie das Parent/Child-Timing aus expliziten span:start/span:end-Zeilen und schreiben Sie den Span-Tree als einzelnen Punkt pro Request in Analytics Engine. Ich habe dies noch nicht über ~5.000 Spans pro Sekunde auf einem einzelnen Worker hinaus getrieben; darüber dominiert der Parsing-Overhead und Sie sollten einen dedizierten OTLP-Collector in Betracht ziehen.
RUM: Web Vitals, auf die Sie tatsächlich reagieren können
Real User Monitoring ist die Ebene, in die die meisten Teams am wenigsten investieren – und es ist die Ebene, die Ihnen zeigt, was Ihre Nutzer tatsächlich erleben.
Für ein B2B-SaaS sind die vier Kennzahlen, die die Conversion maßgeblich beeinflussen, LCP (Largest Contentful Paint), INP (Interaction to Next Paint, FID seit 2024 abgelöst), CLS (Cumulative Layout Shift) und TTFB (Time to First Byte, separat erfasst, da Edge SSR dies handhabbar macht). First Contentful Paint, Total Blocking Time und Speed Index verfolge ich nicht – das sind diagnostische Kennzahlen, keine Lead-Indikatoren.
Die Schwellenwerte, die ich als „gesund auf p75" behandle, sind LCP unter 1,8s, INP unter 200ms, CLS unter 0,05 und TTFB unter 400ms. Diese stammen aus den „guten" Schwellenwerten der Web Vitals plus meiner eigenen Beobachtung, dass das Unterschreiten teuer ist und das Überschreiten Conversions kostet.
Sampling, das nicht täuscht
Den ersten Fehler beging ich mit einem Session-basierten Sampling von 100 % – bei einem Tenant mit wenig Traffic waren das 47 Sessions pro Woche, statistisch bedeutungslos. Den zweiten Fehler beging ich mit einem globalen Sampling von 10 % – genug Sessions, aber zu wenige bei langsamen Routen, um eine Regression zu erkennen.
Das funktionierende Muster ist adaptives per-Route-Sampling: 100 % bei Routen mit <1.000 täglichen Pageviews, 10 % zwischen 1.000 und 100.000, 1 % darüber. Jede Route bleibt repräsentiert, während das Gesamtvolumen begrenzt bleibt:
// src/lib/rum.ts
function sampleRate(routeDailyPV: number): number {
if (routeDailyPV < 1000) return 1.0;
if (routeDailyPV < 100_000) return 0.1;
return 0.01;
}
Melden Sie die Samplerate in dasselbe Analytics-Engine-Dataset wie die Metrik, damit Sie unverzerrte Perzentile berechnen können. Die Metrik ohne Samplerate zu melden ist ein Fehler – Ihre Dashboards gewichten leise die beliebtesten Routen unter.
Synthetics: Die Routen, die niemals ausfallen dürfen
RUM zeigt Ihnen, was Nutzer gesehen haben. Synthetics zeigen Ihnen, was gerade jetzt passieren würde, wenn ein Nutzer es versuchen würde. Sie ergänzen sich, sie sind nicht redundant.
Was Sie synthetic-checken sollten und was nicht
Ich führe Synthetic Checks für drei Kategorien durch: Die Anmelde- und Login-Endpunkte (ein Ausfall dort ist stundenlang in Umsatz-Dashboards unsichtbar), die öffentlichen Marketing-Seiten (SEO-Crawler sehen sie als Nutzer) und die Webhook-Receiver (ein Ausfall eines upstream-Anbieters sieht wie Ihr eigener aus, wenn Sie sie nicht unterscheiden können). Internal Admin Pages oder anything behind authentication prüfe ich nicht per Synthetic.
Für Edge-Apps ist der natürliche Wahlpunkt ein Cloudflare Worker, der auf einem Cron Trigger jede Minute läuft, jede geschützte Route aufruft, das Ergebnis in Analytics Engine aufzeichnet und bei einer rollierenden 5-Minuten-Ausfallrate alertet. Im Vergleich zu Drittanbieter-Synthetic-Services ist der In-Platform-Ansatz für Routen, die vom selben Edge-Netzwerk bedient werden, günstiger und hat geringere Varianz. Die ehrliche Grenze: Mein Coverage beträgt eine Region pro Check. Ich habe kein Multi-Region-Grid deployed; das ist eine bekannte Lücke.
SLIs, SLOs und Alerts, die aus den richtigen Gründen pingen
Die wirkungsvollste Veränderung an meiner On-Call-Lebensqualität war der Ersatz von „Alert bei Schwellenwertüberschreitung" durch „Alert bei SLO-Burn-Rate".
Was ein SLO Ihnen tatsächlich bringt
Ein SLI ist ein Verhältnis – erfolgreiche Requests / Gesamtrequests, p95-Latenz unter Zielwert / Gesamtrequests, was auch immer zum Nutzerwert passt. Ein SLO ist ein Zielwert für dieses Verhältnis über einen Zeitraum – zum Beispiel 99,9 % der Requests innerhalb von 30 Tagen erfolgreich. Der Punkt eines SLOs ist, dass es Ihnen ein Error Budget gibt: Das System darf einen Teil der Zeit ausfallen, und Sie entscheiden im Voraus, wie viel.
Dieser Rahmen kehrt das Alerting um. Statt zu pingen, wenn eine Metrik seltsam aussieht, pingen Sie, wenn das SLO zu schnell brennt – wenn hochgerechnet das Budget vor Ende des Zeitfensters erschöpft sein wird. Die Mathematik folgt Googles Multi-Window, Multi-Burn-Rate Alerting: Ein schnelles Brennen pingt sofort, ein langsames Brennen erstellt ein Ticket.
Ein konkretes SLO für eine SaaS-API
Für die API eines typischen TanStack-Ship-Kunden setze ich das Availability-SLI als 2xx + 3xx Responses / Gesamtresponses, ohne 4xx und Synthetic Checks. Das SLO ist 99,9 % über 30 Tage, was etwa 43 Minuten erlaubte Ausfallzeit pro Monat ergibt. Das Latency-SLI ist Requests unter 800 ms p95 / Gesamtrequests, SLO 99 % über 30 Tage.
Ein Fast-Burn-Alert feuert, wenn 2 % des monatlichen Budgets in 1 Stunde verbraucht werden – etwa 52 Sekunden. Ein Slow-Burn-Alert feuert, wenn 10 % in 6 Stunden verbraucht werden – etwa 4,3 Minuten. Beide leiten an denselben Kanal weiter; der schnelle weckt jemanden, der langsame ist eine Vorwarnung.
Was Sie tun, wenn das Budget aufgebraucht ist
Wenn ein Slow-Burn anhält und das Budget sich vor Ende des Zeitfensters erschöpft, ist die Antwort nicht mehr Alerts – es ist ein Freeze nicht-kritischer Deployments, bis Zuverlässigkeitsarbeit ausgeliefert ist. Mir ist das zweimal passiert; beide Male wurde die aufgeschobene Zuverlässigkeitsarbeit innerhalb einer Woche erledigt. Das Error Budget ist eine Handlungsaufforderung für Arbeit, die Ihr Team immer wieder vor sich herschiebt.
Die Kostenökonomie in drei App-Größen
Eine häufige Frage von Gründern ist, ob der Cloudflare-native Stack wirtschaftlich skaliert. Die ehrliche Antwort lautet: Ja bei meinen Volumina, aber beobachten Sie die Kurve.
Workers Analytics Engine berechnet pro geschriebenem Datenpunkt und pro Abfrage. Workers Logs ist im Workers-Paid-Plan bis zu einem großzügigen Kontingent enthalten. Tail Workers laufen als standardmäßige Workers, abgerechnet nach CPU-Zeit. Über 12 Apps bei einem repräsentativen mittelgroßen Kunden – 8 Mio. Requests/Monat, 200.000 Unique Users, 50 Routen – liegen die kombinierten Observability-Kosten im niedrigen zweistelligen Dollarbereich pro Monat. Ich habe dies nicht bei demselben Volumen mit Datadog oder Honeycomb validiert; die öffentlichen Preislisten sind die maßgebliche Quelle.
Zwei Schwellenwerte verändern die Rechnung. Über etwa 100 Mio. Analytics-Engine-Writes pro Monat dominiert der per-Write-Preis und Sie sollten aggressiver sampeln. Über etwa 10 Mio. Log-Zeilen pro Tag lohnt sich ein Tail Worker mit explizitem Sampling. Ich habe keine App in diesem Maßstab betrieben; dies sind Extrapolationen aus der Preismathematik.
Würde ich eine regulierte Workload mit expliziten Uptime-SLAs betreiben, würde ich für eine Drittanbieter-Observability-Plattform bezahlen – nicht für die Metriken, sondern für das Audit Trail, SOC-2-Evidenz und Compliance-Reporting, das integriert verfügbar ist. Für ein Early-Stage-SaaS, bei dem die Alternative überhaupt kein Monitoring ist, ist der In-Platform-Stack eindeutig besser als eine Drittanbieter-Plattform, die Sie sich noch nicht leisten können. Für ein Series-B-SaaS mit Enterprise-Kunden kehrt sich die Rechnung um.
Ein Entscheidungs- und Implementierungsframework
Bewerten Sie Ihr Projekt anhand dieser Fragen, bevor Sie irgendetwas instrumentieren.
Der Fünf-Fragen-Filter
- Wissen Sie, was Ihre Nutzer sehen? Falls nein, ist RUM das Erste, was Sie bauen.
- Wissen Sie, was Ihr Code tut? Falls nein, ist strukturiertes Logging das Zweite.
- Können Sie „Warum ist dieser Request fehlgeschlagen?" in unter fünf Minuten beantworten? Falls nein: Traces für die langsamen Pfade.
- Feuern Ihre Alerts mehr als einmal pro Woche und lösen sich von selbst? Falls ja: Sie alerten auf Symptome, nicht auf SLOs.
- Können Sie Ihrem Enterprise-Kunden sagen, wann Ihr letzter Incident war und wie lange er dauerte? Falls nein: Ihre Statusseite ist eine Lüge.
Die Reihenfolge meiner Implementierung ist die Reihenfolge der Fragen: RUM, Logs, Traces, SLOs, Statusseite.
Die Standardkonfiguration in TanStack Ship
Die oben beschriebene Sequenz umfasst etwa 1.800 Zeilen Glue Code – RUM-Collector mit adaptivem Sampling, strukturierter Logger mit Redigierung, Analytics-Engine-Writer mit begrenzter Kardinalität, Tail-Worker-Span-Grouperer, SLO-Burn-Rate-Alerter und Statusseiten-Generator. Das erste Mal hat es mich etwa 14 Stunden gekostet und wurde bei jeder der 12 Apps danach progressiv weniger – deshalb habe ich es in ein Modul extrahiert. Wenn Sie es nicht zum dreizehnten Mal schreiben möchten, ist das der Observability-Modul von TanStack Ship.
Fazit
Performance-Monitoring und Observability sind im Jahr 2026 keine einzelne Produktkategorie; sie sind eine geschichtete Praxis. Die Schichten sind RUM, strukturierte Logs, Metriken, Traces, SLIs und SLOs, Synthetics und eine ehrliche Statusseite. Jede Schicht hat eine passend dimensionierte Implementierung am Edge – Workers Analytics Engine für günstige Zeitreihen, Workers Logs und Tail Workers für unstrukturierte Details, Cron Triggers für Synthetics, ein Burn-Rate-Alerter fürs Paging. Die Schichten potenzieren sich: RUM ohne Logs sagt Ihnen, dass etwas nicht stimmt; Logs ohne SLOs sagen Ihnen nichts darüber, ob es relevant ist; Metriken ohne Sampling lügen im großen Maßstab.
Dies ist bewusst ein umfassender Artikel statt sieben enger Einzelthemen. Die drei Säulen, RUM, Synthetics, SLO-Mathematik, Alerting und Kostenökonomie sind alle hier. Für Vertiefung zu einer einzelnen Schicht finden Sie im SaaS Performance Optimization Guide, im Cloudflare Workers Production Guide und im Real User Monitoring Implementation Guide.
Falls Sie entschieden haben, dass Observability wichtig ist und Sie lieber von einer funktionierenden Basis starten möchten als mit einer leeren console.log, sehen Sie sich TanStack Ships 14 Module an oder zeigen Sie die Preise. Einmalige Lizenz, lebenslange Updates, 14-Tage-Rückgabefenster.
Bauen Sie sich RUM und strukturierte Logs selbst, wenn Sie das Wochenende dafür haben. Kaufen Sie sie zurück, wenn Sie es lieber auf den Teil Ihres Produkts verwenden möchten, den niemand anderes bauen kann.
Weiterführende Lektüre: