Kubernetes (on-prem + AWS)
Pods, Events, Deployments, HPA-States, Node-Pressure. Direkt aus eurer Kube-API, ohne Sidecar in jedem Namespace.

Für das DeepL Platform Team
Der Kontext aus dem letzten Post-Mortem, in dem Moment, in dem der nächste Incident anfängt. Kein 'wer hat das damals gefixt'.
Integrationen
On-prem Kubernetes + Ceph, AWS dazu, GitOps mit Crossplane und ArgoCD. Wir haben das gelesen und gebaut, bevor wir mit euch reden.
Pods, Events, Deployments, HPA-States, Node-Pressure. Direkt aus eurer Kube-API, ohne Sidecar in jedem Namespace.
OSD- und MON-Status, PG-Verteilung, Object-Pool-Health, Slow Ops. Ceph-typische Failure-Modes sind eingebaut, nicht zusammengeprompted.
EC2, EKS, RDS, S3, IAM. CloudWatch-Anomalien und CloudTrail-Events landen als Evidence im Incident, neben den On-Prem-Signalen.
State-Diff zwischen letztem Apply und Cluster-Realität. Drift wird im Briefing benannt, mit Pfad zur betroffenen Resource.
GitOps-Diffs werden Teil des Investigation-Reports: was sollte gerade laufen, was läuft tatsächlich, seit wann auseinander.
Prometheus, Loki, Tempo, Elastic, Datadog, PagerDuty. Hyground korreliert über die Quellen, die ihr schon habt, statt eine neue zu fordern.
Aus eurem Team gehört
Aus unseren Gesprächen mit eurem Team kommt das gleiche Bild: cross-team Kommunikation ist der Zeitfresser im Incident, und Docs sind das zweite Problem. Gartner sieht dasselbe Muster über die gesamte Branche.
Der IC trommelt vier Leute aus drei Teams zusammen, bevor jemand weiß, was zuletzt deployed wurde.
Post-Mortems werden geschrieben. Sechs Wochen später findet sie niemand mehr im richtigen Moment.
Der nächste IC startet wieder bei null. Slack-Suche, Wiki-Suche, 'frag mal Tim'.
Im Incident
Der Agent zieht Signale aus euren bestehenden Systemen zusammen, nicht aus einem neuen Datenstore.
Hyground hat eure Doku in der Knowledge Base. Vergangene Incidents tauchen als Evidence im aktuellen auf, automatisch.
Hypothese, Evidence, betroffene Services, letzter relevanter Change. Strukturiert und nachvollziehbar.
Euer in-house Agent
Aus eurem Team haben wir gehört: 'agent mit einigen MCPs angebunden, funktioniert relativ gut für den geringen Aufwand'. Das ist State of the Art für ein internes Pilot-Setup. Drei Dinge, die in der Skalierung typischerweise als nächstes wehtun:
Bei komplexen Incidents braucht es Spezialisierung. Hyground orchestriert mehrere Agenten: Triage, Investigation, Knowledge, Action.
Wiederholbare Operationsabläufe als versioniertes Asset, nicht als Prompt in einer Notion-Page. Audit, Diff, Wiederverwendung.
Self-hosted in eurem VPC oder On-Prem. Keine Daten verlassen die DeepL-Umgebung. EU AI Act und DSGVO sind bereits abgebildet.
So läuft ein Incident mit Hyground
Alert bis Briefing in unter zwei Minuten. Ohne dass jemand das Wiki öffnet.
Hyground bekommt das Alert direkt aus Prometheus, Datadog oder PagerDuty, je nach Quelle.
Logs, Traces, Metrics, letzte ArgoCD-Syncs, Terraform-State-Drift und AWS CloudTrail-Events werden parallel abgefragt und korreliert.
Wenn das schon einmal passiert ist, kommt das Post-Mortem mit. Inklusive Verweis auf Fix und Person.
Strukturierter Report im Slack-Channel oder im Incident-Tool eurer Wahl, mit Empfehlung für den nächsten Schritt.
Hyground läuft in eurem Kubernetes-Cluster, eurer Cloud-Region oder On-Prem. Keine Telemetrie zu uns, keine Inference außerhalb eures Netzwerks. GDPR und EU AI Act sind Baseline, nicht Roadmap.
Video-Walkthrough
Seht euch an, wie Hyground einen Alert aufnimmt, Logs, Metrics und Traces korreliert, das passende Post-Mortem aus der Knowledge Base zieht und dem IC ein strukturiertes Briefing liefert. Echter Run, kein Slide-Deck.
Wir zeigen euch am Beispiel eines eurer Incident-Typen, wie das aussehen würde. Kein Slide-Deck, sondern ein realer Run.