Finanzen & Märkte

Empirik startet mit 21 Millionen Dollar – Ausfälle sollen früher auffallen

|Autor: QUASA-Redaktion|5 Min. Lesezeit
Empirik startet mit 21 Millionen Dollar – Ausfälle sollen früher auffallen

Empirik ist am 1. September 2026 aus dem Stealth-Modus herausgetreten und wird als eigenständiges Unternehmen weitergeführt. Der TechCrunch-Bericht zum Start beziffert die Seed-Finanzierung auf 21 Millionen Dollar und nennt Sequoia Capital, Canapi Ventures und Alumni Ventures als Geldgeber; zu den ersten Kunden gehören demnach Guardant Health und weitere Großunternehmen.

Empiriks Startbeitrag spricht von mehr als 21 Millionen Dollar, nennt zusätzlich S32 und führt Sequoia sowie S32 als führende Investoren auf. Das Unternehmen verspricht, Risiken geplanter Infrastrukturänderungen vor ihrer Bereitstellung sichtbar zu machen; dass sich Ausfälle damit zuverlässig verhindern lassen, ist bislang jedoch nicht unabhängig belegt.

Wer Empirik finanziert und wie das Unternehmen entstand

Empirik baut nach der Seed-Finanzierung seine Software für produktive Unternehmensumgebungen aus.

Die beiden veröffentlichten Summen beschreiben den Start nicht ganz gleich: TechCrunch nennt eine Seed-Runde über 21 Millionen Dollar, Empirik das gesamte eingeworbene Kapital von mehr als 21 Millionen Dollar. Ohne weitere Aufschlüsselung lässt sich nicht feststellen, ob die kleine Differenz allein aus Rundung entsteht oder ob die Unternehmensangabe zusätzliches Kapital einbezieht. Bewertung, Beteiligungsquoten und Investitionsbeträge der einzelnen Geldgeber wurden nicht genannt.

Sequoia ist nicht nur Kapitalgeber, sondern war an der Entstehung beteiligt. Sequoias Gründungsbericht beschreibt, wie Avon Puri und Sudheer Dhurjati die erste Version innerhalb der Beteiligungsgesellschaft entwickelten, bevor Empirik ausgegründet und Kartik Chandrayana als CEO eingesetzt wurde. Chandrayana war zuvor unter anderem für Observability-Produkte bei Salesforce verantwortlich und zuletzt Chief Product Officer bei Quantum Metric.

Diese Herkunft erklärt, warum Empirik bereits vor dem öffentlichen Start Zugang zu komplexen Unternehmensumgebungen hatte. Sie ist aber auch eine wichtige Grenze der verfügbaren Belege: Aussagen von Empirik und Sequoia über Leistung und Kundennutzen stammen von Parteien, die wirtschaftlich am Erfolg des Unternehmens interessiert sind.

Wie Empirik Änderungen vor dem Deployment prüfen will

Empirik prüft die Folgen eines Pull Requests über verbundene Infrastrukturkomponenten hinweg vor dem Deployment.

Empirik setzt nicht erst bei einer Fehlermeldung an, sondern bei der geplanten Änderung. Ein Pull Request, ein Ticket oder ein Schritt in einer automatisierten Pipeline liefert die beabsichtigte Aktion. Die Software soll diese Absicht mit einem laufend aktualisierten Modell der tatsächlichen Infrastruktur verbinden und daraus den möglichen Wirkungsbereich – den sogenannten Blast Radius – ableiten.

Die von Empirik herausgegebene technische Produktbeschreibung nennt Cloud- und lokale Systeme, Kubernetes, virtuelle Maschinen, Identitäts- und Zugriffsverwaltung, CI/CD sowie SaaS-Anwendungen als Teile dieses Modells. Riskante Änderungen sollen vor der Ausführung markiert oder blockiert werden; freigegebene Aktionen sollen innerhalb vorgegebener Kontroll- und Genehmigungsabläufe ausführbar sein.

Das Produktversprechen besteht damit aus drei getrennten Leistungen: Empirik muss die beabsichtigte Änderung korrekt erfassen, die relevanten Abhängigkeiten möglichst vollständig abbilden und aus beiden Informationen eine belastbare Risikobewertung erzeugen. Erst danach folgt die Automatisierung. Wie viel Handlungsspielraum die Software erhält, hängt laut Unternehmensdarstellung von den Freigaben und Leitplanken des jeweiligen Kunden ab.

Der Titel dieser Meldung ist deshalb bewusst als Ziel formuliert: Ausfälle sollen früher auffallen. Präziser geht es darum, das Risiko einer Änderung zu erkennen, bevor überhaupt ein Ausfall entsteht. Eine Warnung ist noch kein Beweis, dass das System den späteren Fehler korrekt vorhergesagt oder verhindert hätte.

Warum das mehr als klassische Observability sein soll

Klassische Observability wertet Metriken, Protokolle und Traces aus laufenden Systemen aus. Sie zeigt beispielsweise steigende Fehlerraten oder ungewöhnliche Latenzen und hilft nach einer Störung bei der Ursachenanalyse. Incident-Response-Software setzt ebenfalls nach oder während eines Vorfalls an und unterstützt Untersuchung, Koordination und Behebung.

Empirik verschiebt den Prüfpunkt zeitlich nach vorn. Eine Einordnung von TechTimes beschreibt die Abgrenzung so: Statt erst Symptome zu verarbeiten, soll Empirik eine Änderung abfangen und deren mögliche Folgen im Abhängigkeitsmodell berechnen, bevor sie ausgerollt wird. Das Produkt ist damit eher eine vorgeschaltete Kontrollschicht als ein Ersatz für Monitoring und Störungsmanagement.

Diese Abgrenzung ist technisch plausibel, aber die Qualität steht und fällt mit dem Infrastrukturmodell. Fehlende externe Dienste, nicht erfasste Berechtigungen oder veraltete Beziehungen können die Bewertung unvollständig machen. Zudem entstehen Ausfälle nicht ausschließlich durch geplante Deployments; Hardwarefehler, Angriffe oder Störungen externer Anbieter liegen außerhalb dieses engeren Prüfpfads.

Kunden sind bestätigt, Vorhersagequalität noch nicht

Empirik prüft eine geplante Änderung in einer produktiven Umgebung von Guardant Health, während bestehende Dienste weiterlaufen.

Empirik startet nicht ohne Unternehmenseinsätze. Öffentlich genannt sind Guardant Health, Avahi Systems und TCBPay sowie ein nicht bezeichnetes Fortune-50-Unternehmen aus der Konsumgüterbranche und ein Fortune-500-Anbieter von Finanzdaten. Die Veröffentlichungen beschreiben diese Einsätze als produktiv, nennen aber weder die Zahl zahlender Kunden noch Vertragsvolumen, Laufzeiten oder die Abgrenzung zwischen Pilot- und Regelbetrieb.

Sequoia führt konkrete Beispiele an: TCBPay erkenne Änderungen an sensiblen Konfigurationsdateien nun in zehn Sekunden statt in 30 Minuten, Avahi habe Empirik in GitHub Actions eingebunden und Guardant Health den Einsatz auf Entwicklungs- und lokale Systeme erweitert. Das sind spezifische Kundenangaben, aber keine unabhängigen Vergleichstests. Sie messen zudem unterschiedliche Dinge – Erkennungszeit, Integration und Ausweitung des Einsatzes – und belegen nicht unmittelbar, wie viele Ausfälle verhindert wurden.

Für einen belastbaren Nachweis fehlen veröffentlichte Werte zur Trefferquote, zu Fehlalarmen, übersehenen Abhängigkeiten und tatsächlich vermiedenen Störungen. Ebenso offen bleibt, wie zuverlässig das Modell in sehr unterschiedlichen Unternehmenslandschaften skaliert. Die Finanzierung und eine frühe Kundenbasis sind damit bestätigt; Empiriks entscheidendes Versprechen, Änderungsrisiken so genau zu berechnen, dass Ausfälle vor dem ersten Alarm verhindert werden können, muss sich erst anhand überprüfbarer Betriebsdaten bewähren.

Lesen Sie auch:

Teilen:

Newsletter abonnieren

Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.

0