Data Freshness Monitoring: Warum veraltete Daten gefährlicher sind als keine

Letzten Dienstag hat dein Team eine Pricing-Entscheidung auf Basis von Wettbewerbsdaten getroffen. Die Logik war sauber, die Zahlen sahen richtig aus. Drei Tage später entdeckst du: Die Quelle hat seit sechs Wochen nicht aktualisiert. Der Wettbewerber hatte schon vor zwei Monaten umgepreist. Du hast auf eine Realität reagiert, die nicht mehr existierte.

Das ist die stille Gefahr veralteter Daten. Sie sehen aus wie frische Daten. Sie haben Werte. Sie passieren Validierungen. Sie zeigen sich schön im Dashboard. Sie reflektieren nur nicht die Gegenwart.

TL;DR

• Pipeline-Erfolg ≠ frische Daten. Eine Pipeline kann erfolgreich laufen und stale Daten ziehen.
• Dashboards zeigen keine Staleness an — du brauchst aktives Freshness-Monitoring.
• Pro Quelle eigene SLA: stündliche Wetter-API vs. quartalsweiser Behörden-Datensatz.
• Partial Staleness ist die heimtückischste: 40 Records aktualisiert, 160 nicht — MAX(timestamp) wirkt frisch.
• Monitor deine Monitore.

Warum Daten still veralten

API Rate Limiting: Pipeline hittet um 3 Uhr morgens ein Limit, stoppt still. Job markiert sich als "complete". Morgen sind die Daten 18 Stunden zurück, ohne Error in Logs.

Source-Website ändert sich: Du scrapest. Provider strukturiert um, CSS-Klassen ändern, Daten hinter Login. Dein Scraper läuft weiter — gibt leere Results oder zieht falsche Elements.

Provider-Side-Delays: Auch Datenanbieter haben Pipelines. Ein Finanz-Daten-Anbieter hat selbst 24h Delay. Deine Pipeline lädt erfolgreich Daten, die schon stale sind.

Credential-Ablauf: OAuth Refresh Tokens, SSL-Zertifikate, API-Tokens — wenn Auth still failt, kommt nichts zurück oder Proxy-Cached-Responses.

Schema-Änderungen: Ein Feld wird umbenannt, deine Extraction gibt überall NULL zurück.

Warum Dashboard-Monitoring nicht reicht

Ein Dashboard mit "Umsatz: 1,2 Mio €" sieht gleich aus, egal ob das heute oder letzten Monat war. Kein visueller Cue für Staleness. Du brauchst ein System, das Update-Zeit trackt und mit Threshold vergleicht.

Aktuelle Ansätze

Pipeline-Failure-Alerts

Fängt Hard Failures — Network Errors, Auth-Failures, OOM-Crashes. Fängt nicht Silent Failures: Jobs, die complete melden, aber stale Daten liefern.

Last-Modified Header

Lightweight, effektiv — aber nur für Quellen, die den Header korrekt implementieren.

Row-Count-Monitoring

Plötzlicher Drop = wahrscheinlich Bruch. Fängt nicht den Fall, dass erfolgreich gefetchte Daten selbst stale sind.

Timestamp-Feld-Monitoring

Semantisch genaueste Methode:

SELECT
  MAX(updated_at) AS last_data_point,
  CURRENT_TIMESTAMP AS now,
  DATE_DIFF('hour', MAX(updated_at), CURRENT_TIMESTAMP) AS hours_stale
FROM your_table

Problem: Über Dutzende Quellen mit unterschiedlichen Feldern und SLAs zu operationalisieren.

Der bessere Ansatz: Pro-Quelle-Freshness mit konfigurierbaren Thresholds

Harbinger Explorer trackt pro Quelle, wann zuletzt erfolgreich gefetched wurde und welcher Timestamp in den Daten am neuesten ist. Du fragst das Metadata-Layer direkt ab:

SELECT
  source_name,
  last_crawled_at,
  DATE_DIFF('hour', last_crawled_at, CURRENT_TIMESTAMP) AS hours_since_crawl,
  expected_update_frequency_hours,
  CASE
    WHEN DATE_DIFF('hour', last_crawled_at, CURRENT_TIMESTAMP) > expected_update_frequency_hours
    THEN 'STALE'
    ELSE 'FRESH'
  END AS freshness_status
FROM source_registry
ORDER BY hours_since_crawl DESC

Pro-Plan: Recrawling auf Schedule. Bei Failure oder unerwartet alten Daten Alert.

Advanced Patterns

SLA pro Source-Kritikalität

SELECT
  source_name,
  freshness_threshold_hours,
  hours_since_last_update,
  hours_since_last_update - freshness_threshold_hours AS hours_overdue,
  CASE
    WHEN hours_since_last_update > freshness_threshold_hours * 3 THEN 'CRITICAL'
    WHEN hours_since_last_update > freshness_threshold_hours * 1.5 THEN 'WARNING'
    ELSE 'OK'
  END AS alert_level
FROM source_freshness_report
WHERE hours_since_last_update > freshness_threshold_hours
ORDER BY hours_overdue DESC

Provider-Side-Delays erkennen

SELECT
  source_name,
  last_crawled_at,
  MAX(data_timestamp) AS most_recent_data_point,
  DATE_DIFF('hour', MAX(data_timestamp), last_crawled_at) AS provider_delay_hours
FROM market_data
GROUP BY source_name, last_crawled_at
HAVING provider_delay_hours > 4
ORDER BY provider_delay_hours DESC

Crawl frisch, Quelle stale — Pipeline-Health allein fängt das nicht.

Cross-Source-Korrelation

SELECT 'pricing' AS source, MAX(updated_at) AS last_update FROM pricing_data
UNION ALL
SELECT 'inventory', MAX(updated_at) FROM inventory_data
UNION ALL
SELECT 'competitor_prices', MAX(fetched_at) FROM competitor_data

Eine stale Quelle kompromittiert den Joint-Analyse-Output. Vor kritischer Query checken.

Häufige Fehler

1. Crawl-Time statt Data-Time monitoren. Pipeline kann perfekt laufen und Daten ziehen, die selbst 48h alt sind.

SELECT MAX(event_date) FROM source_table  -- Data Freshness
SELECT MAX(ingested_at) FROM source_table -- Pipeline Freshness

2. Single Global Threshold. Wetter-API stündlich, Behörden quartalsweise. Gleiche Schwelle produziert False Positives und False Negatives.

3. Monitoring selbst nicht überwachen. Auch dein Monitoring kann stale werden.

4. Partial Staleness ignorieren. Wenn die letzten 3 Tage in einem sonst vollständigen Dataset fehlen, fängt MAX() das nicht:

SELECT DATE_TRUNC('day', event_date) AS day, COUNT(*) AS row_count
FROM events
WHERE event_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1 ORDER BY 1

Vergleich

Real-World: 6-Wochen-alte Pricing-Daten

Investment-Research-Team trackte Bewertungsmultiples für 200 Aktien wöchentlich. API-Provider migrierte Infrastruktur, rate-limitete temporär. Pipeline lief, schaffte 40 Companies, stoppte. Job markierte sich als "complete". Dashboard zeigte alle 200 — 160 davon mit Vorwochenstand.

Sechs Wochen später bemerkte ein:e Analyst:in, dass ein KGV verdächtig identisch zu einer Präsentation von vor sechs Wochen war. Research-Note 3 Wochen verzögert, zwei Buy-Empfehlungen wegen stale Data interne Review.

Mit per-Entity Freshness:

SELECT
  company_ticker, last_updated_at,
  DATE_DIFF('day', last_updated_at, CURRENT_DATE) AS days_stale
FROM company_valuations
ORDER BY days_stale DESC
LIMIT 20

Hätte in Woche zwei spätestens gefeuert. Aggregate MAX(updated_at) hätten es verschleiert, weil die 40 frischen Records den Wert nach vorn zogen.

FAQ

Kann ich Drittanbieter-APIs monitoren, die ich nicht kontrolliere? Ja. Jeder HTTP-erreichbare Endpoint kann registriert werden.

Was passiert bei Recrawl-Failure? Failed Recrawls werden geloggt, Source-Status updated. Last-Known-Good bleibt query-bar.

Wie setze ich unterschiedliche Thresholds? Jede Source in HE hat konfigurierbare Metadata, inkl. erwarteter Update-Frequenz.

Gibt es ein Limit? Starter: 10 Crawls/Monat. Pro: 100. Die meisten Teams überwachen 5–20 kritische Quellen.

Stand: 14. Mai 2026.