Alert-Quellen an einem Ort. Ein Vorfall statt zwölf Alarme.
Zabbix, Datadog, Grafana, Prometheus, Sentry, E-Mail und dein Uptimeify-Monitoring melden an eine Stelle. Uptimeify übersetzt jeden Alarm in dieselbe Sprache, bündelt Doppeltes zu einem Vorfall und gibt ihn an dein Team weiter.
Entwickelt und gehostet in der
Europäischen Union
DSGVO-konformes Hosting
in Deutschland
Georedundantes Replikat
in der gesamten EU
Dein Stack bleibt. Er meldet nur an einer Stelle.
Du musst kein Tool austauschen, um sauber zu reagieren. Für die gängigen Monitoring- und Fehlertools gibt es fertige Vorlagen mit passendem Mapping, für alles andere einen frei konfigurierbaren Webhook. Quelle anlegen, Team zuweisen, URL ins Tool kopieren, fertig.
- Fertige Vorlagen für Zabbix, Datadog, Grafana Alerting, Prometheus Alertmanager, Sentry und Beszel, damit Titel, Schweregrad und Host ab dem ersten Alarm stimmen.
- Dein Uptimeify-Monitoring ist schon dabei: Vorfälle aus deinen eigenen Checks landen automatisch im Incident Management, damit du keine zweite Integration pflegst.
- E-Mail und Meldeformular als Quelle: Alarm-Mails aus Altsystemen und Meldungen von Menschen ohne Login werden ebenfalls zu Alarmen, damit nichts am Prozess vorbeiläuft.
Jede Webhook-Quelle bekommt eine eigene Ingest-URL https://uptimeify.io/api/im/ingest/<token>. Das Token in der URL ist der Zugang, es wird genau einmal angezeigt und nur als SHA-256-Hash gespeichert. Nach einer Rotation funktioniert das alte Token noch sieben Tage, damit du ohne Ausfall umstellen kannst.
Zusätzlich verlangst du pro Quelle optional eine HMAC-Signatur (X-Uptimeify-Signature über <timestamp>.<body>, Toleranz ±5 Minuten) oder ein Bearer-Token mit 256 Bit. Jede fehlgeschlagene Prüfung antwortet mit demselben 404 wie ein unbekanntes Token, so verrät die Antwort nichts. Für Zabbix erzeugt Uptimeify einen fertigen Media Type, Beszel spricht über eine generic://-URL.
Jedes Tool spricht anders. Dein Team liest eine Sprache.
Zabbix sagt „Disaster", Sentry sagt „fatal", Grafana sagt „critical". Im Mapping legst du fest, was daraus wird: ein Titel, ein Host, ein Status und ein Schweregrad von Sev1 bis Sev4. So entscheidet dein Team nach Dringlichkeit, nicht nach dem Dialekt des Tools.
- Felder per Pfad zuordnen, mit Fallback und regulären Ausdrücken, damit auch ungewöhnliche Payloads sauber ankommen.
- Schweregrade übersetzen: Jeder Wert des Tools bekommt seinen Platz auf der Skala Sev1 bis Sev4, damit ein Sev1 aus Datadog genauso klingelt wie einer aus Zabbix.
- Mapping testen, ohne jemanden zu wecken: Der Probelauf nimmt die zuletzt empfangene Nachricht und zeigt das Ergebnis, damit du Änderungen prüfst, bevor sie live gehen.
Selektoren sind Punkt- und Klammerpfade wie data.host.name oder alerts[0].id, Fallbacks laufen über a || b, Regex über field =~ /pattern/ (erste Gruppe oder ganzer Treffer, Flags i, m, s, u, durchsucht werden die ersten 4.096 Zeichen). severityMap übersetzt Rohwerte in sev1 bis sev4, resolveValues legt fest, welche Statuswerte einen Alarm auflösen. Ohne gültigen Schweregrad gilt defaultSeverity, Standard sev3.
POST /api/im/sources/:id/test-mapping ist ein Trockenlauf: Er nimmt den Body, sonst die letzte empfangene Payload, sonst das Beispiel der Vorlage, und legt nichts an. test-alert dagegen schickt einen Alarm durch die echte Pipeline und kann pagen. Die Live-Ansicht zeigt die letzten zehn Rohpayloads.
Weniger Lärm, bevor jemand geweckt wird.
Ein flackernder Check, zehn Alarme zum selben Ausfall, ein geplantes Update um Mitternacht: Das alles darf dein Team nicht wecken. Uptimeify bündelt gleiche Alarme zu einem Vorfall, schließt ihn automatisch, wenn das Tool Entwarnung gibt, und hält geplante Arbeiten pro Quelle still.
- Gleiche Alarme, ein Vorfall: Doppelte Meldungen werden über einen Schlüssel gebündelt, damit ein Alarmsturm genau einen Vorfall erzeugt.
- Wartungsfenster pro Quelle: Wiederkehrende Zeiten mit eigener Zeitzone, in denen die Quelle stumm bleibt, damit der Patch-Dienstag keinen Pager auslöst.
- Stummschalten auf Zeit: Eine Quelle lässt sich bis zu einem festen Zeitpunkt pausieren, damit eine bekannte Baustelle nicht die ganze Nacht klingelt.
Alarme mit gleichem dedupKey gehören zum selben Vorfall. Ohne eigenen Selektor ist der Schlüssel ein SHA-1 aus Titel und Host. groupingWindowMinutes fasst zusätzlich Alarme innerhalb eines Zeitfensters zusammen, null gruppiert nur nach Schlüssel. autoResolve (Standard an) schließt den Vorfall, sobald die Quelle ein Resolve schickt.
Pro Quelle sind bis zu 20 Wartungsfenster möglich, jeweils mit Wochentag, from/to und IANA-Zeitzone. snoozeUntil schaltet die Quelle bis zu einem Zeitpunkt stumm. Melden zwei verschiedene Quellen innerhalb von 15 Minuten einen Vorfall zum selben Service oder Host, schlägt Uptimeify eine Zusammenführung vor. Automatisch zusammengeführt wird nichts.
Jede Quelle im Blick. Jeder Alarm angenommen.
Welches Tool erzeugt den meisten Lärm, und wie viel davon wird wirklich zum Vorfall? Die Statistik pro Quelle zeigt es Tag für Tag. Und wenn es brennt, nimmt Uptimeify Alarme sofort an und verarbeitet sie im Hintergrund, damit dein Monitoring nie auf das Incident Management warten muss.
- Statistik pro Quelle: Alarme, gebündelte Duplikate und daraus entstandene Vorfälle pro Tag, damit du laute Quellen gezielt leiser stellst.
- Sofortige Annahme: Jeder Alarm wird dauerhaft gespeichert, bevor er verarbeitet wird, damit auch bei Lastspitzen nichts verloren geht.
- Events-API für eigene Systeme: Interne Skripte und Plattformen schicken JSON mit einem API-Token, damit auch selbst gebaute Prüfungen im selben Prozess landen.
Ein erfolgreicher Ingest antwortet mit 202 Accepted: Der Alarm ist dauerhaft gespeichert, Mapping, Deduplizierung und Paging laufen asynchron. Ist die Queue kurz nicht erreichbar, landet er in einem Ausweichspeicher. Erst ein 503 heißt, dass nichts gespeichert wurde, dann sendest du mit Backoff erneut.
Grenzen: Body bis 256 KB, Verschachtelung bis 20 Ebenen, 300 Requests pro Minute und Quelle, 50 MiB pro Stunde und Organisation, darüber 429 mit retryAfter. POST /api/im/events nimmt beliebiges JSON mit einem organisationsweiten Token an, bis zu 600 Requests pro Minute, und erkennt Titel, Schweregrad, Status und Dedup-Key über gängige Feldnamen. Die Statistik pro Quelle liefert die letzten 30 Tage mit Daten.
Wir überwachen nicht nur. Wir helfen dir beim Verkaufen.
Jedes Uptimeify-Abonnement enthält Zugang zu unserem Success Kit: eine Sammlung erprobter Ressourcen, um dein Monitoring profitabel zu machen.
Service Level Agreement Vorlagen, um professionelle Grenzen mit deinen Kunden zu definieren.
Finde den Sweet Spot für deine Wartungspläne. Berechne Margen basierend auf Prüfintervallen und Supportstunden.
Präsentationen, die nicht-technischen Kunden 24/7-Monitoring erklären. Schließe mehr Wartungsverträge ab.
Nutze automatisierte Berichte, um proaktiv Wert zu kommunizieren, damit Kunden nie fragen, wofür sie bezahlen.
Bereit, Monitoring in ein Profit-Center zu verwandeln?
Sichere dir dein Success Kit und starte noch heute mit der Skalierung.
Häufig gestellte Fragen
Fertige Vorlagen gibt es für Zabbix, Datadog, Grafana Alerting, Prometheus Alertmanager, Sentry und Beszel. Dazu kommen ein frei konfigurierbarer Webhook für jedes Tool, das JSON senden kann, eine E-Mail-Adresse für Alarm-Mails, ein Meldeformular und die Events-API. Dein Uptimeify-Monitoring ist ohne eigene Einrichtung als Quelle verbunden.
Nein. Die Monitoring Bridge bringt Vorfälle aus deinen Uptimeify-Checks automatisch ins Incident Management. Du entscheidest in den Einstellungen, ob die klassischen Monitoring-Alarme zusätzlich weiterlaufen oder nur noch das Incident Management alarmiert. So stellst du um, ohne eine Nacht ohne Alarm zu riskieren.
Ja. Eine E-Mail-Quelle bekommt eine eigene Adresse, an die du Alarm-Mails weiterleitest. Betreff wird zum Titel, und Mails mit „resolved", „recovered" oder „cleared" im Betreff schließen den Alarm. Ausgewertet werden Betreff und Text-Body, reine HTML-Mails liefern deshalb keinen Inhalt für die Zuordnung.
Über das Meldeformular, einen Link ohne Anmeldung. Jede Meldung wird zu einem Alarm und läuft durch dieselbe Weiterleitung und Eskalation wie ein Tool-Alarm. Die Angabe, wie viele betroffen sind, schlägt einen Schweregrad vor. Ein Honeypot und Limits pro Absender halten Spam draußen, und Meldungen werden nie automatisch zusammengeführt.
Gleiche Alarme werden über ihren Dedup-Key zu einem Vorfall gebündelt, dein Team bekommt also einen Vorfall statt hunderter Meldungen. Jede Quelle nimmt bis zu 300 Requests pro Minute an. Wird eine Grenze erreicht, antwortet Uptimeify mit einem klaren 429 und einer Wartezeit, damit dein Tool gezielt erneut senden kann.
Für den technischen Ansprechpartner
Bereit, deine Alarme an einem Ort zu haben?
Verbinde die erste Quelle, prüf das Mapping im Probelauf und lass Uptimeify den Rest bündeln. Dein Stack bleibt, wie er ist. Dein Team hört nur noch, was wirklich zählt.