Stündlich ist nicht Echtzeit

Ein stündlicher Report fragt nicht nach dem aktuellen Zustand, sondern nach der gerade abgeschlossenen Stunde. Was um 14:00:00 UTC passiert, gehört bereits in das nächste Zeitfenster. Der Lauf beginnt deshalb erst, wenn das Zeitfenster geschlossen ist, und veröffentlicht seinen Stand einige Minuten später. Für einen Alarm wäre das viel zu spät. Für eine verlässliche Zusammenfassung ist es genau die gewünschte Verzögerung.

Diese zeitliche Entscheidung trennt den Stundenreport von laufender Betriebsbeobachtung. Ein abgeschlossener Report beantwortet eine andere Frage als Monitoring: Er hält einen begrenzten Zeitraum als prüfbaren Stand der Beobachtungen fest, während Monitoring auf neue Signale reagieren muss. Der Unterschied liegt nicht zuerst in Prometheus, Grafana oder Markdown. Er liegt darin, wie schnell ein neuer Wert eine Reaktion auslösen muss und ob sich die betrachtete Aussage später noch verändern darf.

Der Beitrag „Markdown Reports statt Dashboard-Zwang“ beschreibt bereits den Unterschied zwischen flüchtiger Ansicht und prüfbarem Stand. Hier geht es enger um die Zeitmechanik eines regelmäßigen Produktreports: geschlossene Zeitfenster, verspätete Daten, Wiederholungen und die Grenze zu echter Betriebsbeobachtung.

Zwei Zeitachsen, zwei Aufgaben#

Monitoring arbeitet möglichst nah am Ereignis. Eine Fehlerrate steigt, ein Alarm wird ausgewertet, jemand öffnet Logs und Traces. Neue Daten verändern die Darstellung fortlaufend. Ein Report wartet dagegen, bis sein Zeitraum beendet ist. Er kann dann feststellen, welche Quellen vollständig vorlagen, seine Fakten hashen und denselben Stand später erneut ausliefern.

flowchart LR
    E["Ereignis"] --> M["Live-Metrik<br/>Sekunden bis Minuten"]
    M --> A["Alarm oder Untersuchung"]
    E --> W["geschlossenes Stundenfenster"]
    W --> R["unveränderlicher Report"]
    R --> V["Vergleich und Einordnung"]

Beide Wege dürfen dasselbe Ereignis sehen und trotzdem zu verschiedenen Ergebnissen kommen. Das Monitoring kann um 13:42 auf fünf Fehler in zwei Minuten reagieren. Der Stundenreport hält später fest, dass im Zeitfenster von 13 bis 14 Uhr fünf Fehler bei 1.200 Ausführungen auftraten, welche Quellen abgedeckt waren und ob die Häufung im Vergleich zu früheren Zeitfenstern auffällt.

Eine laufend aktualisierte Oberfläche für die zweite Aufgabe würde unvollständige Zwischenstände zeigen. Während des laufenden Zeitfensters sind Zähler unvollständig. Ein Wert von null um 13:01 sagt fast nichts über die Stunde aus. Ein wachsender Balken lädt dazu ein, Zwischenstände ungekennzeichnet mit abgeschlossenen Stunden zu vergleichen. Ohne Berücksichtigung der unterschiedlichen Abdeckung ist dieser Vergleich nicht belastbar.

Die Grenzen des Zeitfensters#

Die Sammlung verwendet halboffene UTC-Intervalle. Anfang eingeschlossen, Ende ausgeschlossen. Diese Schreibweise verhindert, dass ein Ereignis an der Grenze in zwei Reports landet.

type ClosedWindow = {
  from: string; // inclusive RFC 3339 timestamp
  to: string;   // exclusive RFC 3339 timestamp
  bucket: "hour";
};

const window: ClosedWindow = {
  from: "2026-07-18T13:00:00.000Z",
  to: "2026-07-18T14:00:00.000Z",
  bucket: "hour"
};

UTC vermeidet einen unangenehmen Sonderfall: In Europa hat der Tag der Sommerzeitumstellung nicht immer 24 lokale Stunden. Speicherung und Sammlung bleiben deshalb in UTC. Die Reportseite kann ein Datum später für ihre Leser lokalisieren, ohne die fachliche Grenze zu verändern.

Zwischen dem Ende des Zeitfensters und der Frischeprüfung sieht dieser Ablauf eine ausdrücklich festgelegte Reserve vor. Wird die Sammlung umfangreicher, müssen Startzeitpunkt, Timeout und Prüfgrenze gemeinsam angepasst werden. Eine heimlich verlängerte Reserve würde echte Verzögerungen nur später sichtbar machen.

Verspätete Daten und fehlende Läufe getrennt halten#

Ein HTTP-Aufruf kann vorübergehend fehlschlagen. Ein Workflow kann nach dem Schreiben des Artefakts abbrechen, bevor er seinen Status aktualisiert. Ein Release kann erfolgreich sein, obwohl die Antwort beim Client nicht mehr ankommt. Darum darf ein Retry nicht einfach „noch einmal alles“ bedeuten.

Jeder Lauf hat ein eindeutiges Zeitfenster. Cadence-markierte Reports werden hier als unveränderliche Veröffentlichungen behandelt: Ein einmal veröffentlichter Stundenstand ändert sich nicht mehr. Ein wiederholter erfolgreicher Versuch darf deshalb keinen zweiten, abweichenden Stundenreport für dasselbe Zeitfenster sichtbar machen.

Erst nach der vorgesehenen Reserve wird zwischen verspätet und fehlend unterschieden. Ein verspäteter Lauf kann noch erfolgreich abschließen und denselben Report veröffentlichen. Ein fehlender Lauf hinterlässt eine Lücke in der erwarteten Stundenfolge. Verspätung, Messlücke und geschlossenes Zeitfenster bleiben damit drei getrennte Sachverhalte, die der Report getrennt benennen sollte.

Was aus einer fehlenden Beobachtung folgt#

Ein kritischer Fall für einen Stundenreport ist eine Stunde ohne Daten. Ein Beobachtungsdienst sollte dafür ausdrücklich vier Zustände unterscheiden: Eine Quelle wurde noch nie beobachtet, sie wurde geprüft und der erwartete Inhalt ist nicht vorhanden, sie ist zugangsgeschützt, oder sie ist tatsächlich fehlerhaft. Eine fehlende Beobachtung darf dabei weder als gesunder Zustand noch als Zahlenwert null ausgegeben werden.

Für einen Stundenreport heißt das: Liegt für eine Stunde keine Messung vor, existiert für diese Stunde kein Wert. Der Report darf dann nicht behaupten, es habe null Ereignisse gegeben, denn diese Aussage würde eine Messung unterstellen, die nie stattgefunden hat. Er muss stattdessen ausweisen, dass die Quelle im betrachteten Zeitraum nicht beobachtet wurde und die Aussage offen bleibt. Wurde die Quelle dagegen geprüft und der erwartete Inhalt nicht gefunden, ist dieser Zustand beobachtet; daraus folgt aber nicht automatisch ein allgemeiner Fehlerzähler von null.

Wann Prometheus und Grafana fehlen würden#

Werkzeuge wie Prometheus und Grafana unterstützen unter anderem die laufende Untersuchung: Eine Abfrage lässt sich während der Analyse anpassen und der Zeitraum verschieben. Diese Arbeitsweise ist wertvoll, wenn die Frage nicht vorab feststand.

Eine Oberfläche für Stundenreports kann dagegen auf abgeschlossene Reportzeiträume ausgerichtet sein. Diese Ausrichtung passt, solange die Oberfläche abgeschlossene Zeiträume erklären soll. Für eine Incident-Analyse kämen Warnungen dagegen zu spät, und die stündliche Auflösung reicht für eine Ursachensuche bis auf einzelne Requests nicht aus. Ein stündlicher Report ersetzt weder Alarmierung noch laufende Betriebsbeobachtung; er setzt beides als eigenständige Aufgaben voraus.

Vier Fragen vor der Werkzeugwahl#

„Dashboard oder Report?“ ist zu grob. Vier Fragen trennen die Anforderungen: Reaktionszeit, Veränderlichkeit, Untersuchung und Auflösung.

Die erste betrifft die Reaktionszeit. Muss jemand innerhalb von Sekunden oder wenigen Minuten handeln, gehört die Beobachtung in ein Monitoring- und Alerting-System. Darf ein Team den Stand im nächsten regelmäßigen Arbeitszyklus prüfen, kann ein stündlicher oder täglicher Report reichen.

Die zweite betrifft die Veränderlichkeit. Soll dieselbe URL morgen neue Werte zeigen, ist eine Live-Abfrage passend. Muss später noch genau der Stand vom 18. Juli lesbar sein, braucht es ein unveränderliches Artefakt oder einen ausdrücklich gespeicherten Snapshot.

Die dritte betrifft die Untersuchung. Sind die Fragen vorab bekannt – Anzahl Releases, Fehler, Quellenabdeckung –, kann ein begrenztes Schema sie präzise abbilden. Entstehen die Fragen erst beim Blick auf eine Auffälligkeit, werden Abfragesprache, variable Zeiträume und Drill-down wichtig.

Die vierte betrifft die Auflösung. Ein stündlicher Zähler kann zeigen, dass etwas häufiger fehlschlug. Er kann nicht erklären, welcher einzelne Request langsam war oder welche Logzeile zu einem Trace gehört. Für diese Untersuchung müssen die hochaufgelösten Daten in ihrem Betriebswerkzeug bleiben.

decision:
  reaction_time: next_work_cycle
  immutable_history: required
  questions_known_in_advance: true
  per_request_drilldown: false
result: scheduled_report

Sobald eine Antwort kippt, kann auch das passende Werkzeug wechseln. Ein Report und ein Live-System dürfen denselben Dienst beobachten, solange sie nicht vortäuschen, dieselbe Aufgabe zu erfüllen.

Der Scheduler ist Teil der Aussage#

Ein manuell erzeugter Report belegt nur, dass irgendwann jemand einen Knopf gedrückt hat. Ein geplanter Lauf macht zusätzlich sichtbar, ob die erwartete Regelmäßigkeit eingehalten wurde. Eine Prüfung dieser Regelmäßigkeit muss deshalb zwischen geplanten und manuell ausgelösten Läufen unterscheiden: Manuelle Läufe dürfen eine ausgefallene geplante Stunde nicht verdecken, sonst zählt die Prüfung Erfolge, die nichts über die Zusage der Regelmäßigkeit aussagen.

Auch eine Pause ist kein Fehler, wenn sie während eines Releases ausdrücklich gesetzt wurde. Sie muss jedoch sichtbar sein und nach dem Rollout bewusst aufgehoben werden. Ein vergessener Pause-Schalter ist kein Datenproblem, sondern eine unterbrochene Zusage über Regelmäßigkeit.

Was ein Stundenreport erklären muss#

Ohne ausgewiesene Quellenabdeckung kann ein Operator eine Messlücke als Ergebnis lesen. Ein Stundenreport muss deshalb selbst erklären, worauf er sich stützt. Überblick, Frage, Schlussfolgerung und nächste Handlung lassen sich aus demselben semantischen Report-Dokument ableiten; ein zweiter, parallel gepflegter Dashboard-Datensatz ist dafür nicht nötig. Eine passende Oberfläche zeigt diese Antwort in abnehmender Wichtigkeit: zuerst Zustand und Ausnahme, dann wenige Signale, danach Evidenz und Provenienz.

Eine Seite mit dreißig Metriken ohne Frage ist schwerer zu prüfen als eine Seite mit einer klaren Frage, einem belegten Stand und einer benannten nächsten Entscheidung. Die Faktendefinition muss dafür auch Datenlücken abbilden: Sie sollte vorhandene, fehlende und veraltete Quellen getrennt nennen, damit eine offene Aussage nicht wie eine beantwortete aussieht.

## Data quality

The source window is complete for four product APIs.
External acquisition data is not connected yet and is shown as unavailable.
No value is inferred from missing input.

Auch die Aggregation braucht eine Erklärung. Eine wöchentliche Median-Laufzeit beantwortet eine andere Frage als das Maximum der langsamsten Stunde. Der Report nennt Zeitraum, erwartete und vorhandene Unterfenster sowie die verwendete Verdichtung. Sonst sieht eine präzise Zahl geprüfter aus, als sie ist.

Verdichtung über größere Zeiträume#

Tages-, Wochen-, Monats- und Jahresreports entstehen aus bereits abgeschlossenen Artefakten. Ein Tagesreport kann auf den unveränderlichen Stundenständen aufsetzen, statt dieselben Quellen für jede Stunde erneut abzufragen, und dabei ausweisen, welche Stundenfenster ihm fehlen. Cadence-markierte Reports bleiben unveränderliche Veröffentlichungen; ein Rollup ersetzt keinen Stundenstand, er verdichtet ihn.

flowchart TD
    H["24 Stundenartefakte"] --> D["Tagesreport"]
    D --> W["Wochenreport"]
    W --> M["Monatsreport"]
    M --> Y["Jahresreport"]
    H --> Q["Abdeckung und fehlende Fenster"]
    Q --> D

Ein Tagesreport, dem einzelne Stundenfenster fehlen, kann trotzdem hilfreicher sein als gar kein Report – aber nur, wenn er sich klar als unvollständig ausweist. Er darf nicht dieselbe visuelle Sicherheit ausstrahlen wie ein vollständig abgedeckter Zeitraum. Die Datenqualität gehört neben die Kennzahlen, nicht in eine Fußnote.

Eine Oberfläche kann den neuesten abgeschlossenen Zeitraum vor weiteren Entscheidungshorizonten und einer begrenzten Historie anordnen. Welche Frage jeder gröbere Report beantwortet, ist eine Gestaltungsentscheidung. Eine naheliegende Aufteilung: Die Stunde prüft den Datenfluss und frische technische Signale. Der Tag beantwortet, was heute Aufmerksamkeit braucht. Die Woche vergleicht Tagesverläufe und wiederkehrende Ausnahmen. Der Monat ordnet Aktivitätsmuster, Betriebsrisiken und Messlücken für die nächste Planung ein. Das Jahr verdichtet nur jene Evidenz, die eine strategische Entscheidung tragen kann. Nur den Datumsfilter zu verbreitern wäre formal korrekt und inhaltlich schwach.

Auch Zahlen sind dabei nicht bloß Werte. Eine Faktendefinition sollte Zähler, Bestände, Laufzeiten, Verhältnisse und Datenmengen unterscheiden, die Einheit nennen und festlegen, ob ein Rollup Summe, letzten Wert oder Mittelwert bevorzugt. Eine Maschine muss dann nicht aus einem Metriknamen raten, wie der Wert über mehrere Intervalle gelesen werden soll.

Einfache Technik braucht eine klare Grenze#

Der stündliche Ansatz kann ohne zusätzliche, dauerhaft laufende Auswertungsplattform auskommen, wenn vorhandene Systeme Sammlung, Planung und Veröffentlichung übernehmen. Seine Fragen stehen vor dem Lauf fest, und sein Ergebnis erscheint als unveränderliche Veröffentlichung. Entscheidend ist die Verantwortungsgrenze: Der Report sammelt, schließt ab und veröffentlicht; die laufende Beobachtung bleibt bei den dafür gebauten Systemen.

Diese Einfachheit bleibt nur erhalten, wenn das System zu seiner Aufgabe steht. Ein Report darf eine fehlende Datenquelle zeigen, statt eine neue Datenerfassung heimlich einzubauen. Er darf auf eine externe Incident-Ansicht verweisen, statt selbst zur Leitstelle zu werden. Und er darf eine Frage unbeantwortet lassen, wenn dafür weder Fakt noch Connector vorhanden ist.

Stündlich bedeutet hier nicht „fast live“. Es bedeutet: regelmäßig, abgeschlossen, wiederholbar und langsam genug, um einen vollständigen Stand zu prüfen. Wer schneller reagieren muss, braucht Monitoring und Alarmierung. Wer später nachvollziehen will, was in einem klaren Zeitraum bekannt war, braucht einen Stundenreport. Beide bestehen nebeneinander, mit klar zugeordneten Aufgaben: Monitoring liefert laufende Signale, Alarmierung stößt daraus eine Reaktion an, und der Stundenreport bewahrt den abgeschlossenen, prüfbaren Beobachtungsstand.

Weiterführende Quellen#

• Prometheus Overview
• Grafana Dashboards
• W3C Trace Context