Service-Status und Verfügbarkeit prüfen

Zweck und Einsatzbereich

Die vorbereitete öffentliche Seite NeuraPort Status zeigt einen Gesamtzustand und die Komponenten Application API, Database und Interface monitoring. Sie benötigt keine Anmeldung und aktualisiert ihre Daten nach dem Öffnen sowie anschließend im Minutenabstand. Der angezeigte Zeitpunkt stammt aus der jeweils neu erzeugten Statusantwort.

Diese Seite ist eine schmale Zustandsübersicht, keine Verfügbarkeitsgarantie. Operational bedeutet lediglich, dass die Statusanfrage beantwortet wurde, eine einfache Datenbankprobe gelang und die berücksichtigten globalen Schnittstellenmonitore keinen Fehler oder veralteten Test melden. Es bestätigt weder Anmeldung noch Fachprozesse, Dateiablage, Hintergrundjobs, E-Mail, Kundenportal, öffentliches Tracking oder einen bestimmten Mandantenprovider.

Im Repository sind die Statusseite und ihre öffentliche Datenantwort vorhanden. Eine eigene veröffentlichte Status-Domain, deren Proxyzuordnung und ein Link von der Produktwebsite sind dort jedoch nicht vollständig belegt. Verwenden Sie die Statusseite erst als Betriebsnachweis, wenn der Plattformbetrieb ihre tatsächliche Bereitstellung, den Ziel-Build und die Datenweiterleitung für die konkrete Umgebung bestätigt hat.

Voraussetzungen und Berechtigungen

Die öffentliche Statusseite und ihre Datenantwort benötigen keine Anmeldung. Interne Benutzer dürfen sie als erste Orientierung verwenden. Plattformoperatoren benötigen für eine vollständige Störungsanalyse zusätzlich die getrennt autorisierten Betriebswege für Basisgesundheit, Schnittstellenkonfiguration, Deployment, Proxy, Scheduler und Protokolle. Plattformoperatoren ist hier eine Betriebsaufgabe, keine automatisch belegte Produktrolle.

Prüfen Sie vor der Bewertung, welche Umgebung betroffen ist: Produktiv-, Demo- oder eine isolierte Testumgebung. Eine erreichbare Demo darf nicht als Nachweis der Produktion verwendet werden. Eine Demo-Kennzeichnung wiederum beweist weder technische Isolation noch funktionierende externe Provider.

Für die Fachprüfung benötigen Sie den regulär berechtigten Testzugang und freigegebene synthetische Daten. Verwenden Sie keine fremden Konten, veröffentlichten Demo-Zugangsdaten, vollständigen Tracking-Links oder echten Kundendaten. Plattformoperatoren dokumentieren nur Umgebung, Zeitpunkt, Statuswerte, betroffenen Bereich und letzte sichere Aktion; Hostnamen, interne Adressen, Tokens, Schlüssel und Verbindungsdaten gehören nicht in Screenshots oder Tickets.

Eine positive Statusseite ersetzt keine kontrollierte Fachstichprobe. Umgekehrt darf ein fachlicher Fehler nicht allein aufgrund eines grünen Gesamtstatus als Benutzerfehler abgetan werden. Rechte, Lizenz, Organisationseinheit, Providerkonfiguration und Datenzustand bleiben eigenständige Fehlerquellen.

Schritt-für-Schritt-Anleitung

Öffentliche Statusseite einordnen

Öffnen Sie die vom Plattformbetrieb bestätigte öffentliche Statusseite in einem privaten Browserfenster. Verwenden Sie keinen erratenen oder aus internen Unterlagen kopierten Host.
Prüfen Sie zuerst den Gesamtstatus: Operational, Degraded, Outage, Maintenance oder Unknown.
Lesen Sie jede sichtbare Komponente einzeln. Application API bestätigt nur die Antwort des Statuswegs. Database bestätigt nur eine einfache Datenbankverbindung. Interface monitoring fasst ausschließlich aktive globale Monitore zusammen.
Prüfen Sie Last updated. Die Seite fragt regulär alle 60 Sekunden neu ab. Fehlt der Zeitpunkt, zeigt die Seite einen Status-API-Fehler. Ein alter Zeitpunkt trotz geöffneter Seite ist ein Warnsignal und kein aktueller Nachweis.
Bei Degraded, Outage oder fehlender Aktualisierung stoppen Sie risikoreiche Fachaktionen. Notieren Sie Zeitpunkt, sichtbare Komponenten und die letzte sicher abgeschlossene Aktion.
Bei Operational fahren Sie mit einer gezielten Fachprüfung fort. Bewerten Sie den grünen Zustand nicht als Bestätigung von Portal, Tracking, Provider oder Demo.

Basisgesundheit und Fachweg getrennt prüfen

Plattformoperatoren prüfen über den freigegebenen Betriebsweg die Basisgesundheit. healthy bedeutet, dass Backend und einfache Datenbankprobe antworten. unhealthy mit einer nicht erreichbaren Datenbank ist ein Basisfehler und wird als Dienstfehler behandelt.
Interne Benutzer laden die betroffene Ansicht genau einmal neu. Prüfen Sie Anmeldung, aktive Organisationseinheit, Rolle, Lizenz und sichtbare Fehlermeldung.
Bei einem Providerprozess prüfen berechtigte Personen den konkreten Schnittstellenmodus, letzten Testzeitpunkt, Simulation, Fehler und fachliche Quittung. Eine globale Aggregation ersetzt diese Prüfung nicht.
Prüfen Sie das Kundenportal separat mit einem aktiven, isolierten Portalnutzer. Eine sichtbare Portalanmeldung beweist noch keinen Codeversand, keine Sitzung und keinen Aktenzugriff.
Prüfen Sie öffentliches Tracking separat mit einem neu erzeugten, freigegebenen Testlink. Eine erreichbare Tracking-Seite beweist weder gültigen Token noch aktuelle AIS- oder Carrier-Daten.
Prüfen Sie eine Demo ausschließlich in der eindeutig gekennzeichneten, isolierten Demoumgebung. Simulierte Erfolge dürfen nicht als produktive Providerverfügbarkeit protokolliert werden.
Erst wenn Basiszustand und betroffener Fachweg wiederholt erfolgreich sind, geben Sie den Prozess für die weitere Bearbeitung frei.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
Gesamtstatus	Systemseitig	Zusammenfassung der berücksichtigten Komponenten.	Outage hat Vorrang vor Degraded; Unknown führt im Gesamtbild zu Degraded. Kein SLA-Nachweis.
Operational	Systemseitig	Die berücksichtigten Prüfungen melden keinen Fehler oder veralteten Monitor.	Kann auch erscheinen, wenn keine aktiven globalen Schnittstellenmonitore konfiguriert sind oder nur Simulationen positiv getestet wurden.
Degraded	Systemseitig	Mindestens ein Monitor meldet Fehler oder einen veralteten Zustand beziehungsweise eine Komponente ist unbekannt.	Betroffene Fachfunktion getrennt prüfen; übrige Komponenten können weiterhin funktionieren.
Outage	Systemseitig	Mindestens eine berücksichtigte Komponente meldet Ausfall.	Schreibvorgänge stoppen und über den Betriebsweg eskalieren; keine automatische Aussage zur Ursache.
Maintenance	Systemseitig	Vorgesehener Wartungszustand des Statusmodells.	Im geprüften Komponentenservice wird dieser Zustand derzeit nicht aktiv erzeugt. Nicht ohne angekündigtes Wartungsfenster annehmen.
Unknown	Systemseitig	Komponentenstatus ist nicht feststellbar.	Erscheint für die Schnittstellenaggregation, wenn die Datenbankprüfung ausfällt; Gesamtstatus ist dann wegen der Datenbank bereits Outage.
Application API	Systemseitig	Statusweg antwortet und setzt die Anwendungskomponente positiv.	Keine getrennte Probe von Anmeldung oder Fachrouten; innerhalb einer erfolgreichen Statusantwort stets Operational.
Database	Systemseitig	Ergebnis einer einfachen Datenbankverbindungsprobe.	Bestätigt keine fachliche Abfrage, Migration, RLS-Regel, Sicherung oder Datenvollständigkeit.
Interface monitoring	Systemseitig	Aggregiert aktive globale Schnittstellenkonfigurationen.	Mandantenbezogene Provider sind nicht enthalten. Tests älter als 30 Minuten oder ohne Testzeitpunkt gelten als veraltet.
Last updated	Systemseitig	Erstellungszeitpunkt der zuletzt erfolgreich geladenen öffentlichen Antwort.	Nicht mit Zeitpunkt des letzten Providertests verwechseln. Fehlt beim Status-API-Fehler.
Active monitors	Nur in den Daten, nicht sichtbar	Anzahl aktiver globaler Schnittstellenmonitore.	Null wird als Operational bewertet; die Statusseite rendert diese Zahl derzeit nicht.
OK / Error / Stale / Simulation	Nur in den Daten, nicht sichtbar	Aggregierte Zähler der globalen Monitore.	Die sichtbare Seite zeigt die Zähler nicht; Simulation kann in OK enthalten sein und bestätigt keinen Liveprovider.
Checked at	Nur in den Daten, nicht sichtbar	Prüfzeitpunkt je Statuskomponente.	Die sichtbare Seite zeigt nur den Erstellungszeitpunkt der Gesamtantwort.
healthy / unhealthy	Getrennter Basisweg	Backend- und Datenbank-Basiszustand für den Betrieb.	Keine öffentliche Statuskomponente für Portal, Tracking, Provider, Scheduler oder Dateispeicher.

Status und mögliche Übergänge

Ausgangszustand	Beobachtung oder Ereignis	Bewertung
Seite wird geöffnet	Statusantwort erfolgreich	Gesamtstatus, Komponenten und Last updated erscheinen.
Geöffnete Seite	60 Sekunden vergehen	Eine neue Statusantwort wird angefordert; bei Erfolg ersetzt sie Zustand und Zeitpunkt.
Statusantwort nicht erreichbar	Laden oder Aktualisieren scheitert	Gesamtstatus wird Outage, einzige sichtbare Komponente ist Status API, Aktualisierungszeitpunkt wird geleert.
Datenbankprobe scheitert	Status wird berechnet	Database wird Outage, Interface monitoring wird Unknown, Gesamtstatus wird Outage.
Alle globalen Monitore melden Fehler	Status wird berechnet	Interface monitoring und Gesamtstatus werden Outage, sofern keine abweichende stärkere Bewertung nötig ist.
Einzelner Monitor fehlerhaft oder älter als 30 Minuten	Status wird berechnet	Interface monitoring und Gesamtstatus werden Degraded.
Keine aktiven globalen Monitore	Status wird berechnet	Interface monitoring und Gesamtstatus werden Operational; dies bedeutet „nicht überwacht“, nicht bestätigte Providergesundheit.
Nur aktuelle erfolgreiche Simulationen	Status wird berechnet	Aggregation kann Operational zeigen; externe Livewirkung bleibt unbestätigt.
Status grün, Fachaktion scheitert	Konkreter Prozess wird geprüft	Status bleibt möglicherweise Operational; Fehler ist über Rolle, Lizenz, OE, Daten und Provider separat zu untersuchen.

Was im Hintergrund passiert

Bei jeder öffentlichen Statusanfrage setzt der Dienst einen aktuellen Erstellungszeitpunkt, markiert die Anwendungskomponente als antwortend, führt eine einfache Datenbankprobe aus und liest aktive globale Schnittstellenkonfigurationen. Die Antwort enthält keine Zugangsdaten. Automatisierte Tests bestätigen den anonymen Abruf, die drei Komponentenschlüssel und das Fehlen typischer Geheimnisfelder.

Ein Schnittstellenmonitor gilt als veraltet, wenn kein Testzeitpunkt vorhanden ist oder der letzte Test mehr als 30 Minuten zurückliegt. Ein gespeicherter Fehler hat Vorrang vor „veraltet“. Eine aktuelle Simulation wird separat gezählt, kann aber zugleich als OK gelten. Die Seite rendert nur Bezeichnung, Meldung und farbigen Punkt; Zähler für aktive, erfolgreiche, fehlerhafte, veraltete und simulierte Monitore sowie der komponentenbezogene Prüfzeitpunkt bleiben unsichtbar.

Die Statusantwort startet keine Providertests. Sie liest nur gespeicherte Testergebnisse. Ein eigenständiger periodischer Prüflauf ist vorbereitet, seine tatsächliche Scheduler-Einrichtung ist im Repository aber nicht belegt. Ohne extern aktivierten Scheduler altern Testwerte nach 30 Minuten und führen zu Degraded; bei null globalen Monitoren bleibt die Aggregation dennoch Operational.

Kundenportal und öffentliches Tracking sind eigenständige Frontends und Datenwege. Sie werden weder aktiv von der öffentlichen Statusantwort abgefragt noch als Komponenten dargestellt. Gleiches gilt für Demo-Routing, Codeversand, Trackingtoken, AIS, Carrierquittungen, E-Mail, Websocket, Dateispeicher, Queue, Hintergrundjobs und Backups. Ihre Erreichbarkeit muss mit kontrollierten, nicht destruktiven Fachstichproben geprüft werden.

Eine Live-Browserprüfung ist vorbereitet, läuft aber nur bei ausdrücklicher Aktivierung. Sie prüft Anwendung und Demo auf sichtbares Rendering, die Basisgesundheit, das Portal-Rendering und eine öffentliche Statusantwort. Ihr erwarteter Statuspfad und ihr Datenformat weichen jedoch vom hier implementierten Statusdienst ab. Zusammen mit der fehlenden belegten Status-Proxykonfiguration ist sie deshalb kein Nachweis, dass der veröffentlichte Statusweg mit diesem Build verbunden ist.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
The public status endpoint is currently unavailable.	Statusantwort, Netzwerk, Proxy oder Ziel-Build ist nicht erreichbar.	Zeitpunkt und Screenshot ohne Adresse melden; Plattformbetrieb prüft Bereitstellung, Proxy und Basisgesundheit. Nicht fortlaufend aktualisieren.
Outage bei Database	Einfache Datenbankprobe ist fehlgeschlagen.	Fachliche Schreibvorgänge stoppen und Betriebsstörung eskalieren. Nach Behebung Basis- und Fachweg erneut prüfen.
Degraded bei Interface monitoring	Mindestens ein globaler Monitor meldet Fehler oder ist älter als 30 Minuten.	Konkrete Schnittstellenkonfiguration, Modus, letzten Test und Providerquittung durch Berechtigte prüfen.
Operational, obwohl kein Provider eingerichtet ist	Null aktive globale Monitore wird positiv bewertet.	Operational nicht als Providerbeleg verwenden; konkrete Schnittstelle und Monitoringabdeckung prüfen.
Operational trotz Simulation	Aktueller erfolgreicher Simulationstest wird als OK gezählt.	Simulationsmodus getrennt prüfen; produktive Wirkung nur mit echtem Test und fachlicher Quittung bestätigen.
Last updated ist alt	Automatische Aktualisierung hat nicht erfolgreich abgeschlossen oder die Seite ist nicht mehr aktiv.	Einmal neu öffnen; bleibt der Zeitpunkt alt, als unbekannten Zustand eskalieren.
Status bleibt grün, Portalcode kommt nicht an	Codeversand und Portalablauf sind keine Statuskomponente.	Portalnutzer, Modullizenz und Versandweg im Portalprozess prüfen; keine wiederholten Codes anfordern.
Status bleibt grün, Tracking-Link scheitert	Trackingtoken, Lizenz, Demo-Weiterleitung und Trackingdienst werden nicht geprüft.	Tokenstatus, Zielumgebung und Tracking-Fachweg intern getrennt prüfen; vollständigen Link nicht weitergeben.
Status bleibt grün, Provideraktion scheitert	Öffentliche Aggregation enthält nicht zwingend den Mandantenprovider oder nur ein gespeichertes Ergebnis.	Mandantenkonfiguration, OE, Lizenz, Live-/Simulationsmodus, Testalter und externe Quittung prüfen.
Basisstatus ist healthy, Fachansicht lädt nicht	Health bestätigt nur Backend und einfache Datenbankprobe.	Browserfehler, Build, Proxy, Authentifizierung, Rechte, Lizenz, OE und Fachroute getrennt prüfen.
Erwartete Statusseite ist nicht auffindbar	Veröffentlichung oder Verlinkung des vorbereiteten Assets ist nicht bestätigt.	Keine Adresse erraten. Den freigegebenen Statuszugang beim Plattformbetrieb erfragen und Deploymentnachweis prüfen.
Live-Smoke-Test und Statusantwort passen nicht zusammen	Vorbereiteter Test erwartet einen anderen Pfad und ein anderes Datenformat.	Test, Proxy und aktuellen Build auf einen gemeinsamen Vertrag bringen; bis dahin keinen automatischen Statusnachweis behaupten.