Private Status-Seiten. Nur für die, die es angeht.
Nicht jeder Status gehört ins Internet. Gib eine Seite nur für angemeldete Kunden frei, nur per SSO, mit Passwort oder nur aus bestimmten Netzen, und zeig jeder Gruppe nur die Dienste, die sie betreffen.
Entwickelt und gehostet in der
Europäischen Union
DSGVO-konformes Hosting
in Deutschland
Georedundantes Replikat
in der gesamten EU
Öffentlich, angemeldet oder per SSO. Du entscheidest pro Seite.
Die Seite für die Endkunden deines Kunden darf jeder sehen. Die Seite mit dem internen ERP, den Schnittstellen und dem Staging nicht. Pro Status-Seite stellst du ein, wer Zugang hat: alle, nur angemeldete Mitglieder des Kunden, nur Konten über euren Identity Provider oder jeder mit dem Passwort.
- Nur für Kunden-Mitglieder, damit eine interne Seite nur sieht, wer ohnehin Zugriff auf den Kunden hat.
- Nur per SSO, damit Zugang und Entzug über denselben Identity Provider laufen wie alles andere.
- Passwortschutz für schnelle Freigaben, damit auch Externe ohne eigenes Konto mitlesen können.
`visibility` ist `public`, `customer_members_only`, `sso_members_only` oder `password_protected`. Bei `customer_members_only` brauchen Besucher ein Konto mit Zugriff auf den Kunden, ohne Kunden reicht jedes Mitglied der Organisation. Ohne Sitzung kommt `401`, ohne Zugriff auf den Kunden `404`, damit die Adresse nichts verrät. `sso_members_only` verlangt zusätzlich eine Sitzung über das SSO der Organisation, sonst `401 ssoRequired`, und setzt verifiziertes SSO voraus (`400 ssoNotConfigured`).
Unabhängig davon steuert `isPublished`, ob die Seite überhaupt erreichbar ist. Unveröffentlichte Seiten zeigen angemeldeten Mitgliedern mit Rolle Admin, Editor oder Readonly eine Vorschau mit Hinweisbanner, alle anderen bekommen `404`.
Nur aus dem Firmennetz. Für jeden anderen unsichtbar.
Manche Kunden wollen keinen weiteren Login, aber auch keine öffentliche Seite. Mit einer IP-Allowlist ist die Seite nur aus ihrem Büronetz oder ihrem VPN erreichbar. Die Regel gilt zusätzlich zu jeder Sichtbarkeit, auch für eine sonst öffentliche Seite.
- Bis zu 50 Adressen oder Netze als IPv4 oder IPv6, damit Büros, VPN und Rechenzentrum gemeinsam freigegeben sind.
- Kombinierbar mit jeder Sichtbarkeit, damit eine SSO-Seite zusätzlich nur aus dem Firmennetz erreichbar ist.
- Kein Zwischenspeicher, damit eine geschützte Seite nie in einem fremden Cache liegt.
`ipAllowlist` nimmt bis zu 50 IPv4- oder IPv6-Adressen oder CIDR-Bereiche und speichert sie als `addr/prefix`. `[]` hebt die Beschränkung auf. Geprüft wird die Adresse, die unser Reverse Proxy sieht, nicht `X-Forwarded-For`, ein gefälschter Header hilft also nicht. Gesperrte Besucher bekommen `403 statusPageIpNotAllowed`, das gilt auch für die Passwortprüfung.
Antworten für Seiten mit IP-Allowlist, mit Zielgruppen und für Vorschauen tragen `Cache-Control: private, no-store`.
Eine Seite. Jede Gruppe sieht ihren Teil.
Dein Kunde hat drei Standorte, zwei Partnerfirmen und ein internes IT-Team. Statt fünf Seiten zu pflegen, legst du Zielgruppen an: Jede bekommt ihre E-Mail-Domain und ihre Komponenten. Wer sich anmeldet, sieht nur, was seine Gruppe betrifft, und auch der Gesamtstatus rechnet nur damit.
- Bis zu 20 Zielgruppen pro Seite, damit Standorte, Partner und interne Teams auf einer Seite Platz haben.
- Zuordnung über die E-Mail-Domain, damit niemand Gruppen von Hand pflegen muss.
- Gesamtstatus aus Sicht der Gruppe, damit ein Ausfall am anderen Standort nicht als eigene Störung erscheint.
`audienceGroups` nimmt bis zu 20 Gruppen, jede mit `name` (1 bis 80 Zeichen), `emailDomains` (1 bis 20, exakter Abgleich ohne Subdomains) und `componentIds` (1 bis 100). Besucher brauchen eine Anmeldung mit verifizierter E-Mail-Adresse auf einer der Domains. Komponenten ohne Gruppe sieht jeder, der die Seite sehen darf. Admins und Editoren sehen alles.
Komponenten fremder Gruppen werden ausgelassen, ebenso Vorfälle und Wartungen, die nur diese Komponenten betreffen. `overallStatus` und `overallState` werden aus dem berechnet, was der Besucher sieht. Ein PATCH ersetzt alle Gruppen, `[]` entfernt sie.
Privat heißt privat. Auch für Badge und Feed.
Eine private Seite, deren Status über ein Badge oder eine Abo-Mail nach außen dringt, ist nicht privat. Deshalb gibt es für Seiten mit Login, SSO, IP-Allowlist oder Zielgruppen weder Badge noch Widget noch Feed, und Abos werden nicht angenommen. In der Übersicht siehst du für jede Seite auf einen Blick, wie sie sichtbar ist.
- Kein Badge, kein Widget, kein Feed auf privaten Seiten, damit nichts an der Zugangskontrolle vorbeiläuft.
- Keine Abos auf privaten Seiten, damit keine Mail Inhalte an Personen trägt, die die Seite nicht sehen dürfen.
- Sichtbarkeit in der Übersicht, damit du bei vielen Kunden sofort erkennst, welche Seite öffentlich ist und welche nicht.
Badge (`/status/:slug/badge.svg`), Widget (`/status/:slug/embed`), RSS- und Atom-Feeds und Abos gibt es nur bei `visibility: public` ohne `ipAllowlist` und ohne `audienceGroups`. Alle anderen Seiten antworten dort mit `404`. Der Abo-Endpoint antwortet auch bei privaten Seiten mit `{ "ok": true }` und speichert nichts, er verrät also nicht, dass es die Seite gibt.
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
Eine Status-Seite, die nicht jeder im Internet sehen kann. Bei Uptimeify ist sie nur für angemeldete Mitglieder des Kunden sichtbar, nur per SSO, nur mit Passwort, nur aus bestimmten Netzen oder nur für bestimmte Gruppen. Typische Fälle sind interne Systeme, Partnerportale und Dienste, deren Störungen nicht öffentlich werden sollen.
Ja. Ein gemeinsames Passwort ist der schnellste Weg, eine Seite für einen kleinen Kreis freizugeben, etwa für einen Dienstleister ohne eigenes Konto. Für dauerhaften Zugang großer Gruppen ist die Anmeldung über Kundenkonten oder SSO die sauberere Lösung, weil du Zugänge dann zentral entziehst.
Du stellst die Sichtbarkeit auf „nur per SSO". Besucher melden sich dann über den Identity Provider deiner Organisation an, etwa Microsoft Entra ID, Google Workspace, Okta oder Keycloak. Wer das Unternehmen verlässt, verliert mit dem Konto auch den Zugriff auf die Status-Seite. Voraussetzung ist ein eingerichtetes und verifiziertes SSO.
Ja, über Zielgruppen. Jede Gruppe bekommt eine oder mehrere E-Mail-Domains und die Komponenten, die sie sehen darf. Wer sich anmeldet, sieht nur die Komponenten seiner Gruppe und die Vorfälle dazu. Auch der Gesamtstatus wird nur aus diesen Komponenten berechnet.
Nein, mit Absicht. Abos, Badge, Widget und Feeds gibt es nur für öffentliche Seiten. Eine Mail oder ein Badge würde sonst Inhalte an Personen tragen, die die Seite nicht sehen dürfen. Für private Seiten informierst du über die Seite selbst oder über die Kanäle deines Teams.
Für den technischen Ansprechpartner
Bereit, den Status nur denen zu zeigen, die es angeht?
Leg eine interne Seite für dein Team an, eine geschützte für deinen Kunden und eine öffentliche für seine Endkunden, alle aus einem Dashboard. Jede zeigt genau das, was sie zeigen soll.