Wenn der Auth-Service erreichbar ist, aber 403 Forbidden liefert, liegt die Ursache meist in einer fehlenden oder abgelehnten Autorisierung: Token, Rollen, Scopes oder Claims passen nicht zum Zielendpunkt, oder eine Poli
Wenn das API Gateway als erreichbar („Up“) angezeigt wird, die aufgerufene URL aber 404 liefert, liegt meist kein Verfügbarkeitsproblem vor, sondern ein Routing-, Base-Path-, Stage-, Host- oder Deployment-Mismatch. Prüfe
Prüfe zuerst, ob das Zielsystem hinter dem API Gateway erreichbar und gesund ist. HTTP 503 und Timeouts entstehen in diesem Themenbereich meist durch nicht erreichbare, überlastete oder als unhealthy bewertete Upstream-T
Ein HTTP-200-Health-Check für das API-Management-Admin-Backend ist in der Regel eine erfolgreiche Erreichbarkeitsmeldung und kein Incident.
Prüfe zuerst Backend-Status, Logs, Abhängigkeiten sowie DNS- und Netzwerkpfad. Behebe Hänger, Überlast oder Konfigurationsprobleme und verifiziere anschließend den URL-Health-Check erneut, bevor du Timeouts oder Ressourc
Wenn API-Management-Komponenten einen Hostnamen nicht auflösen können und Fehler wie getaddrinfo EAIAGAIN oder ein Down-Status auftreten, prüfe die Namensauflösung aus genau der betroffenen Laufzeitumgebung. Sind DNS, Re
Wenn das API-Management-Admin-Backend oder das Developer Portal nach rund 48 Sekunden als down gemeldet wird, liegt meist ein Request-Timeout in der Kette aus Monitoring, Reverse Proxy, Gateway, Load Balancer oder Backen
Wenn das Developer Portal oder das Admin Backend nach etwa 48 Sekunden mit „timeout of 48000ms exceeded“ als Down erscheint, liegt die Ursache meist in einer zu langsamen oder blockierten Request-Kette. Prüfe zuerst die
Wenn der Aufruf der API-Management-Admin-Backend-URL mit „timeout of 48000ms exceeded“ abbricht, liegt die Ursache meist in einer zu langen Verarbeitung oder in einer langsamen bzw. nicht erreichbaren Abhängigkeit. Prüfe
Prüfe zuerst die DNS-Auflösung und dann die komplette Kette aus Gateway, Proxy, Load Balancer, Health Check und Upstream. Bei "Down", Timeout um etwa 48 Sekunden oder HTTP 503 liegt die Ursache oft im Requestpfad oder in
Prüfe zuerst Zielservice, Abhängigkeiten und Gateway/Proxy/Load-Balancer; ein Timeout nach rund 48 Sekunden entsteht meist durch eine nicht rechtzeitig antwortende Komponente, einen Upstream-Fehler oder eine problematisc
Wenn APIM bei fehlender Tenant-Berechtigung 200 OK statt 403 Forbidden liefert, den Ablehnungszweig im APIM-Policy-Flow prüfen und sicherstellen, dass der Fehlerpfad den HTTP-Status explizit auf 403 setzt und später nich
Prüfe zuerst Endpunkt-Erreichbarkeit, Dienststatus, Logs und DNS-/Load-Balancer-/Upstream-Abhängigkeiten. Der Fehler ist meist ein Timeout im Authentifizierungsdienst oder in einer abhängigen Komponente; Timeout-, Retry-
Prüfe zuerst, ob das Problem aus einer bestehenden Browser-SSO-Session, einer Proxy-/Ingress-Fehlkonfiguration oder einer Störung in der SSO-/IdP-Backend-Kette stammt. Je nach Symptom helfen Session-Reset, Korrektur der
Prüfe zuerst, ob der Ziel-Endpunkt, der Reverse Proxy/Ingress und der Upstream-Dienst erreichbar sind. Timeouts und HTTP 503 entstehen in diesem Cluster meist durch einen ausgefallenen oder zu langsamen Backend-Dienst, e
Wenn der Login ins CKAN-Portal sowohl per SSO als auch ohne SSO mit HTTP 500 endet, liegt meist ein serverseitiger Fehler in CKAN, der Authentifizierungskette, dem Reverse Proxy, der Sessionverwaltung oder der Datenbank-
Ein HTTP 503 beim Daten-Dashboard bedeutet meist, dass das Dashboard selbst oder eine vorgeschaltete Proxy-, Ingress- oder Load-Balancer-Schicht den Dienst aktuell nicht gesund bereitstellt. Prüfe zuerst Health-Checks, L
Wenn der Produktions-Endpunkt des Daten-Dashboards im Browser oder per HTTP-Request HTTP 200 OK liefert und das Monitoring ihn als Up anzeigt, liegt in der Regel kein Störungsfall vor. Den Check erneut verifizieren und d
Wenn der Developer-Portal-Check HTTP 200 OK liefert, ist das in diesem Topic in der Regel kein Incident, sondern ein erfolgreicher Erreichbarkeits- oder Uptime-Check. Prüfe die Ziel-URL und die Monitoring-Logik; wenn der
Prüfen Sie zuerst die Namensauflösung aus der betroffenen Laufzeitumgebung. getaddrinfo EAIAGAIN weist meist auf einen temporären DNS-/Resolver-Fehler, eine fehlerhafte Resolver-Konfiguration oder einen blockierten DNS-P
Prüfe zuerst, ob der Generic Auth Service den Hostnamen oauth.futr-hub.de aus seiner Laufzeitumgebung auflösen kann. Bei getaddrinfo EAIAGAIN liegt sehr häufig ein temporäres DNS-/Resolver-Problem, eine fehlerhafte Resol
Ein Endpoint-Check mit HTTP 200 OK bedeutet in diesem Kontext, dass der DWD-API-Endpunkt im PROD-Use-Case erreichbar ist und die Anfrage erfolgreich verarbeitet wurde. Bei wiederholt 200 OK liegt kein Hinweis auf eine St
Prüfe zuerst den Gesundheitszustand des Generic Auth Service, dann Logs, Downstream-Abhängigkeiten und die Proxy-/Timeout-Schicht. Der Fehler deutet typischerweise auf ein Erreichbarkeits- oder Antwortzeitproblem des Die
Prüfe Ingress-, Reverse-Proxy- und Auth-Proxy-Konfiguration, Allowlist/ACL, Host- und URL-Matching sowie die Weitergabe der relevanten Header. Ein HTTP 403 weist in diesem Muster meist auf eine Ablehnung auf Proxy-/Autor
Prüfe zuerst Route, Host und Path-Rewrite in Ingress, Reverse Proxy oder API-Gateway sowie die Verfügbarkeit des bereitgestellten Endpunkts im PROD-Deployment. Ein HTTP-404 deutet hier meist auf falsches Routing oder ein
Wenn der Aufruf des Generic Auth Service mit "timeout of 48000ms exceeded" fehlschlägt, prüfe zuerst Erreichbarkeit, Latenz, Logs und Downstream-Abhängigkeiten sowie Gateway-/Proxy-Timeouts. Der Fehler ist meist ein Symp
Prüfe zuerst den Health- oder Ziel-Endpoint direkt, dann Logs, Abhängigkeiten und den Netzpfad. Bei einem 48-Sekunden-Timeout liegt die Ursache meist im Service selbst, in einer nachgelagerten Komponente oder in Proxy-/E
Prüfe zuerst die Namensauflösung und Erreichbarkeit des Auth-Endpunkts, dann den Zustand des Generic Auth Service und seiner Abhängigkeiten. Ein Timeout von 48 Sekunden deutet meist auf einen hängenden, überlasteten oder
Prüfe zuerst Erreichbarkeit, Antwortzeit und Abhängigkeiten des Generic Auth Service. Wenn der Health-Check wegen eines Timeouts fehlschlägt, liegen die Ursachen meist im Service selbst, in vorgelagerten Proxy-/Gateway-S
Wenn der Generic Auth Service im produktiven URL-/Health-Check mit „timeout of 48000ms exceeded“ als Down erscheint, ist meist der Auth-Endpunkt selbst zu langsam oder eine vorgelagerte Abhängigkeit blockiert die Antwort
Wenn der Generic Auth Service mit „timeout of 48000ms exceeded“ als down erscheint, prüfe zuerst Dienststatus, Logs und abhängige Systeme. Häufig liegt die Ursache in Überlast, einem Hänger, einer langsamen Upstream-Abhä
Wenn der Geo Auth Service in PROD mit einem Timeout und Down-Status auffällt, prüfe zuerst Erreichbarkeit, Health-Status, Logs und vorgeschaltete Infrastruktur. Häufig liegen die Ursachen bei langsamen oder nicht erreich
Im PROD zuerst Health-Checks, Logs und Abhängigkeiten prüfen; wenn der Dienst hängt, kontrolliert neu starten und nur nach Ursachenanalyse Timeout oder Konfiguration anpassen.
Wenn der Geo Auth Service erreichbar ist, aber HTTP 403 Forbidden liefert, liegt meist kein Verfügbarkeitsproblem vor, sondern eine Autorisierungs- oder Policy-Sperre. Prüfe zuerst, ob der 403 vom Geo Auth Service selbst
Wenn der Geo Auth Service in Produktion als nicht erreichbar erscheint oder nach 48 Sekunden mit Timeout abbricht, prüfe zuerst Erreichbarkeit, Logs, Abhängigkeiten und Ressourcenauslastung. Behebe nur die bestätigte Urs
Prüfe zuerst den Healthcheck und die Logs des Geo Auth Service sowie der vorgeschalteten Komponenten. Ein Timeout nach 48 Sekunden deutet meist auf ein Problem im Service selbst, in einer abhängigen Komponente, in der Ne
Ein HTTP-404 beim Geo Auth Service bedeutet in der Regel, dass der aufgerufene Pfad nicht auf einen gültigen Endpoint gemappt ist. Prüfe zuerst die aufgerufene URL, dann Routing/Reverse-Proxy/API-Gateway und zuletzt, ob
Prüfe zuerst, an welcher Stelle im Geo-Auth-Aufrufpfad die 48-Sekunden-Grenze greift: Service-Erreichbarkeit, vorgeschaltete Proxys oder Load Balancer, Downstream-Abhängigkeiten, Health-Checks und letzte Deployments. Wen
Wenn der Geo Auth Service im Produktivsystem mit timeout of 48000ms exceeded ausfällt, zuerst den betroffenen Endpunkt und den Fehlerzeitraum eingrenzen, dann Logs, Abhängigkeiten, DNS/Netzwerk und Ressourcen prüfen. Ein
Wenn der GeoDienst-Basisdaten-Endpunkt im PROD mit HTTP 200 OK antwortet, ist er zum Prüfzeitpunkt erreichbar und gesund. In diesem Fall gibt es keinen Incident-Fix, sondern nur die Bestätigung des Befunds und gegebenenf
HTTP 503 bedeutet in der Regel, dass der GeoDienst oder eine vorgeschaltete Komponente vorübergehend nicht verfügbar ist. Prüfe zuerst den betroffenen Endpunkt, dann Upstream, Proxy/Ingress, Logs und letzte Änderungen; n
Der Fehler entsteht typischerweise, wenn ein Request in der Kette aus Client, Proxy/Load Balancer und Backend nicht rechtzeitig beantwortet wird. Prüfe zuerst den direkten Endpunkt, dann die Timeout-Werte entlang der Ket
Prüfe zuerst Logs, Latenzen und die komplette Request-Kette des Geoportal-Endpunkts. Das Symptom „timeout of 48000ms exceeded“ entsteht meist durch eine zu langsame Antwort des Endpunkts selbst oder durch eine vorgeschal
Für Geoportal-Zugriffe zuerst prüfen, ob das Benutzerkonto bereits existiert, dann die passende Rolle oder Zugriffsgruppe zuweisen, eine notwendige Provisionierung/Synchronisation anstoßen und den erfolgreichen Login bzw
Ein HTTP 403 bei einem erreichbaren Auth-Service bedeutet meist nicht einen Ausfall, sondern eine Ablehnung auf Authentifizierungs-, Autorisierungs- oder Gateway-Ebene. Prüfe zuerst, wo der 403 erzeugt wird, danach Token
Wenn ein Auth-Service als „Up“ angezeigt wird, aber HTTP 403 Forbidden liefert, liegt die Ursache meist in der Authentifizierung/Autorisierung oder in einer vorgeschalteten Komponente wie Ingress, Gateway, Reverse Proxy
Wenn ein Geo Auth Service oder Generic Auth Service zwar erreichbar ist, aber HTTP 403 Forbidden liefert, liegt die Ursache meist nicht an der Verfügbarkeit, sondern an einer Zugriffs- oder Autorisierungsblockade. Typisc
Wenn ein Auth- oder Zugriffsservice trotz Status „Up“ mit HTTP 403 antwortet, liegt die Ursache meist bei fehlender oder ungültiger Autorisierung, einer ACL/Allowlist, oder einer vorgeschalteten Policy in Gateway, Proxy
Ein HTTP-404 beim Weather-Use-Case deutet meist auf eine falsche oder veraltete Endpoint-Konfiguration hin. Prüfe Basis-URL, Pfad, API-Version und Umgebungsvariablen in der Staging-Konfiguration und gleiche den Request m
Prüfe zuerst den betroffenen UI-/Backend-Dienst, seine Abhängigkeiten und den Ingress/Reverse Proxy. HTTP 500 spricht meist für einen Anwendungsfehler, HTTP 503 meist für einen nicht verfügbaren oder nicht gesunden Upstr
HTTP 503 (Service Unavailable) bedeutet in diesem Kontext meist, dass der betroffene Geo-Dienst, ein Upstream oder die vorgelagerte Proxy-/Load-Balancer-Schicht den Request nicht verarbeiten konnte. Prüfe zuerst Dienstst
Ein HTTP 503 im Daten-Dashboard bedeutet meist, dass ein vorgelagerter Proxy, Load Balancer oder ein Backend-/Upstream-Dienst den Request vorübergehend nicht bedienen kann. Prüfe zuerst, wo die 503 erzeugt wird, dann die
Ein HTTP 503 bedeutet in diesem Kontext meist, dass der Endpoint oder ein nachgelagerter Upstream-Dienst im STG nicht verfügbar oder nicht gesund ist. Prüfe zuerst den Endpoint, danach Health Checks, Proxy-/Ingress-Logs,
HTTP 503 bedeutet, dass der Zielservice oder eine vorgelagerte Komponente den Request aktuell nicht bedienen kann. Prüfe zuerst den betroffenen Endpoint, dann Upstream, Proxy/Load-Balancer und externe Abhängigkeiten; bei
Ein HTTP 503 bedeutet in diesem Kontext meist, dass der aufgerufene Dienst, ein vorgeschalteter Upstream oder die Gateway-/Proxy-Schicht vorübergehend nicht verfügbar ist. Prüfe zuerst Dienststatus und Health-Checks, dan
Ein HTTP 503 bedeutet meist, dass der GeoDienst oder eine vorgelagerte Komponente das Backend als nicht verfügbar einstuft. Prüfe zuerst den betroffenen Endpunkt, dann Backend, Proxy/Gateway, Health Checks, Logs und letz
Ein HTTP 503 bei der Postgres Management UI oder Datenbank-UI bedeutet meist, dass der UI-Endpunkt oder ein vorgelagerter Layer zwar erreichbar ist, aber keinen gesunden Backend-Dienst findet oder die Anfrage nicht weite
Ein HTTP 503 in Geo-Plattform-Diensten zeigt meist an, dass der angefragte Dienst, ein Upstream oder der vorgeschaltete Proxy/Ingress keine gesunde Antwort liefern kann. Prüfe zuerst Dienststatus und Health-Checks, dann
Ein HTTP 503 oder HTTP 500 bedeutet in diesem Kontext meist, dass die Management UI oder ein Portal-Backend nicht verfügbar, nicht bereit oder durch eine Abhängigkeit gestört ist. Prüfe zuerst den Dienststatus, dann Prox
Wenn ein Identity-Access-Dienst in PROD als nicht erreichbar gemeldet wird und Timeouts oder HTTP 503 liefert, prüfe zuerst Dienstgesundheit, dann DNS-, Proxy-/Ingress- und Upstream-Pfad sowie abhängige Services. In den
Prüfe zuerst den betroffenen Request am Reverse Proxy bzw. Load Balancer, danach Applikation, Backend und Datenbank. Ein 48-Sekunden-Timeout ist meist ein Symptom einer blockierten, überlasteten oder zu langsamen vorgela
Ein HTTP-503-Fehler im Open Data Portal bedeutet meist, dass der Dienst oder ein Upstream dahinter nicht erreichbar bzw. nicht gesund ist. Prüfe Portal, Reverse Proxy/Load Balancer, Health Checks, Logs und letzte Änderun
Ein HTTP 503 im Open Data Portal deutet meist darauf hin, dass der Backend-Dienst, ein abhängiger Upstream oder der vorgeschaltete Reverse Proxy/Load Balancer keine gültige Antwort liefern kann. Prüfe zuerst Backend-Stat
Wenn der Open-Data-Portal-Endpunkt im Produktionsbetrieb mit HTTP 200 OK und Status Up antwortet, liegt in der Regel keine Störung vor. Der Eintrag dient dann als Bestätigung des Betriebszustands und kann als „kein Fehle
Bei HTTP 500 im Open Data Portal liegt meist ein serverseitiges Problem in der Portal-Anwendung oder einer abhängigen Komponente vor. Prüfe zuerst Logs und die zuletzt betroffene Anfrage, dann Backend-, Datenbank-, Authe
Wenn das Open Data Portal in Produktion wegen „timeout of 48000ms exceeded“ als Down gemeldet wird, liegt meist ein zu langsamer Request, eine blockierte Abhängigkeit oder ein Engpass in Backend, Datenbank oder Gateway v
Wenn das Open Data Portal einen Endpoint als down meldet und ein Timeout von 48000 ms auftritt, ist meist der Endpunkt, eine vorgelagerte Abhängigkeit oder eine Proxy-/WAF-Stufe zu langsam oder blockiert. Prüfe Erreichba
Prüfe zuerst die SSO-Konfiguration in Staging im Vergleich zu Prod, teste den alternativen Loginpfad und kontrolliere anschließend den pgAdmin-Servereintrag für die geo-static-Datenbank inklusive DNS, Netzwerk, TLS und D
Wenn die Postgres-Datenbank-UI im PROD als Up gemeldet wird und HTTP 200 OK liefert, liegt in der Regel kein Incident vor. Verifiziere den Check kurz; wenn der Befund reproduzierbar ist, behandle den Alarm als False Posi
Prüfe zuerst UI-, Backend-, Proxy/Ingress- und PostgreSQL-Logs im betroffenen Zeitfenster. Die häufigste Ursache ist ein langsamer oder hängender Request bzw. Health-Check; danach DB-Blockaden, Release-/Rollout-Effekte u
Prüfe zuerst, welcher Endpunkt nach rund 48 Sekunden abbricht, und analysiere dann die Kette aus Portal/Admin-Backend, Proxy/Gateway und abhängigen Diensten. Ein Timeout wird nachhaltig nur behoben, wenn die verursachend
Ein Timeout von 48000ms bei einer Management-UI oder einem Portal deutet meist auf eine langsame oder blockierte Abhängigkeit hinter Frontend, Gateway oder Proxy hin. Prüfe zuerst Erreichbarkeit, Logs und die Upstream-Ke
Wenn die S3 Management UI in PROD mit 200 OK antwortet und als Up gemeldet wird, liegt aus Sicht des Health-Checks kein Verfügbarkeitsfehler vor. Prüfe den Status erneut; bleibt er stabil, dokumentiere den Check als erfo
Ein HTTP-200-OK-Health-Check der S3-Management-UI bedeutet zunächst nur, dass der Endpoint erreichbar ist. Ohne zusätzliche Fehlermeldungen oder Nutzersymptome ist das kein technischer Ausfall, sondern ein positiver Verf
Der Fehler deutet darauf hin, dass der Aufruf aus der S3-Management-UI an die nachgelagerte S3-/Backend-Komponente nicht innerhalb des UI-Timeouts beantwortet wurde. Prüfe zuerst Erreichbarkeit, DNS, Netzwerkpfad, Antwor
Prüfe zuerst, welcher Alerting- oder SMS-Kanal tatsächlich sendet, ob die Zielnummer korrekt formatiert und zugeordnet ist, löse dann einen eindeutigen Test-Alert aus und verifiziere Übergabe, Versand und Empfang über di
Wenn in Superset Staging weder SSO noch lokaler Login funktionieren und keine Reset-Mail versendet wird, prüfe zuerst die Authentifizierungs-Konfiguration, anschließend den Mailversand für Passwort-Resets sowie die dazug
Wenn die Datenbank-UI mit „Client network socket disconnected before secure TLS connection was established“ ausfällt, liegt das Problem meist vor oder während des TLS-Handshake-Pfads. Prüfe zuerst Zielerreichbarkeit, Pro
Prüfen Sie zuerst den direkten HTTPS-Zugriff auf den S3-Endpunkt, anschließend TLS-Versionen, Zertifikatskette, Hostname/SNI und den Netzwerkpfad. Der Fehler deutet typischerweise darauf hin, dass die Verbindung vor Absc
Wenn der geprüfte PROD-Endpunkt mit HTTP 200 OK antwortet und der Health-Check als Up bewertet wird, liegt aus Sicht der Verfügbarkeit kein Fehler vor. In diesem Fall geht es vor allem um die korrekte Bewertung des Check
Weise in Grafana die Viewer-Rolle zu, konfiguriere in Apache Superset eine lesende Rolle wie Gamma oder eine gleichwertige Read-only-Rolle, prüfe das Rollenmapping über SSO/IdP und stelle sicher, dass keine Passwortwechs
Ordne die Benutzer einer klaren Read-Only-Rolle zu, prüfe pro System, ob authentifizierter oder öffentlicher Zugriff vorgesehen ist, und kontrolliere externe Passwort-Policies separat, damit kein erzwungener Passwortwech
Ein 403 bedeutet meist, dass die Anfrage ankommt, aber nicht autorisiert ist. Eine 404 bei anonymem Zugriff kann ebenfalls absichtlich sein, wenn eine geschützte Ressource verborgen wird. Prüfe zuerst Sichtbarkeit und Be