QUELLEN & METHODIK

Bedeutung des Status.

Berichte, Beobachtungen und fehlende Daten bleiben getrennt.

Offizielle Berichte

Verzeichnis umfasst 56 AI-Dienste in Assistenten/Suche, Coding, Medien, Modell-APIs, Inferenz/GPU-Cloud und Vektordatenbanken. 37 haben automatische Quellen, plus 11 allgemeine Dienste. Redaktionelle Auswahl, keine Beliebtheitsmessung oder vollständige Branche. Wir speichern Berichte, bestätigen AI-Verfügbarkeit nicht unabhängig.

Claude- und GitHub-Zusammenfassungen enthalten Komponenten, Ereignisse und Wartung. Andere kompatible Quellen können Listen auslassen; dies wird ausdrücklich angezeigt. OpenAIs erfasster Endpunkt liefert derzeit nur Komponentenzustände. ChatGPT- und API-Zusammenfassungen verwenden getrennte feste, verifizierte Komponenten-IDs; neue oder fehlende IDs erfordern Prüfung. Verfügbarkeit bezieht sich nicht auf einzelne Modelle, Tarife oder Konten.

Copilot, v0, Replicate, Workers AI und AI Gateways nutzen ihre spezifischen Komponenten auf gemeinsamen Anbieterseiten. Gesamtindikator und fremde Ereignisse werden nicht zugeordnet. Fehlt eine ausgewählte Komponente, wird kein neuer Bericht gespeichert.

Hugging Face, Together AI, Modal, Runpod und Qdrant verwenden öffentliches Better-Stack-JSON. Referenzierte Ressourcen und Updates müssen vorliegen. Gelöste Berichte sind auch ohne Endzeit ausgeschlossen. Ressourcenzeiten werden nicht aus Seitenzeit erfunden. DeepInfras Dienst- und Modellstatus sind Anbieterbeobachtungen; vom Anbieter als veraltet markierte Antworten werden abgelehnt. Dieser Adapter importiert keine Ereignis- oder Wartungsdetails.

Vercel und Cloudflare bieten Plattformberichte und separate Ansichten einzelner Produkte. Supabase verwendet den veröffentlichten Plattformindikator und die derzeit aufgeführten Komponenten; diese können nur einen Teil der Plattform abdecken und bestätigen nicht jede Region oder jedes Projekt. Notion/Resend nutzen verifizierte neue Domains ohne Ereignis-/Wartungslisten. Slack-v2 liefert Status/Ereignisse mit Funktionsnamen, keine komplette Komponentenmatrix. Geplante Slack-Einträge separat ohne erfundene Wartungsfenster.

Stripe nutzt die verifizierte neue Statusdomain für Komponenten, Ereignisse und Wartung. Auth0 liefert eingebettetes JSON für zehn öffentliche Produktionsregionen ohne Skriptausführung; Private Cloud, Tenantzustand, Details und Wartung fehlen. Fehlende Regionen oder geänderte Seitenidentität verhindern neue Berichte. AWS Health liefert derzeit verifiziertes UTF-16-Big-Endian; Dienste, Regionen, Updates und numerische Codes bleiben erhalten, ohne Schwere/Lösung daraus zu deuten. Gesamtstatus bleibt neutral, bestätigt weder Kontozustand noch AWS-Gesamtverfügbarkeit.

Der öffentliche Google Cloud-Feed wird gegen den Produktkatalog geprüft. Beendete und zukünftige Ereignisse zählen nicht als aktuell. Ohne aktive öffentliche Ereignisse bleibt die Zusammenfassung neutral; sie beschreibt keine Personalized Service Health und bestätigt keine Projektverfügbarkeit unabhängig. Produkt- und Standortnamen bleiben bei Updates erhalten.

Gemini nutzt den Google Workspace-Ereignisfeed, geprüft gegen offiziellen Katalog. Beendete, zukünftige oder fremde Ereignisse werden nicht aktuell. Ohne aktive Ereignisse heißt es „Keine gemeldeten Ereignisse“, nicht betriebsbereit. Letztes Ereignisupdate und Erfassung sind getrennt; ohne Gemini-Ereignisse gibt es keine veröffentlichte Gemini-Zeit.

Grok / xAI liest vierzehn verifizierte Komponenten aus dem öffentlichen JSON seiner offiziellen Statusseite und prüft IDs, Namen und den vollständigen ausgewählten Satz ohne Skriptausführung. Livecharts und Ereignisdetails werden nicht importiert. DeepSeek importiert strukturierte aktive Änderungen; keine Änderungen lassen Verfügbarkeit unbekannt. Beide liefern keine verifizierte Veröffentlichungszeit. fal nutzt Version 3 und sieben verifizierte Komponenten; beide Antworten müssen validieren, fehlende Details oder Zeiten bleiben fehlend. CoreWeave nutzt Status.io mit verifizierten Codes, Komponenten und Standorten; laufende und zukünftige Wartung sind getrennt.

Midjourney nutzt den Produktions-JSON-Feed seiner offiziellen Seite. Dienstüberschriften sind getrennt von Fast-/Relax-Wartezeiten. Wartezeitfarben sind keine Ausfälle oder unabhängigen Latenzmessungen. Anbieterzeit bleibt erhalten; Berichte älter als fünfzehn Minuten oder mehr als dreißig Sekunden in der Zukunft werden abgelehnt.

Google Cloud AI filtert den öffentlichen Feed nach 23 verifizierten Vertex-Produkt-IDs. Andere Ereignisse sind ausgeschlossen; fehlende gewählte Produkte verhindern neue Berichte. Getrennt von Gemini-App und Gemini API / AI Studio. Codex erfasst nur „Codex in ChatGPT Desktop“ in OpenAIs Bericht; dies belegt keine CLI-, IDE- oder Cloud-Aufgabenverfügbarkeit.

Gemini API, Google AI Studio und Google Cloud AI sind getrennt von diesem Gemini-App-Feed. Gemini API / AI Studio hat eine eigene offizielle Statusseite; die automatische Erfassung dieser Seite ist nicht implementiert. „Nur offizielle Seite“ bezeichnet eine verlinkte Statusseite ohne automatische Erfassung. „Nicht angebunden“ bedeutet keine Statusdaten; verlinkte Produktwebsites sind als Website gekennzeichnet.

Erfassung und Aktualität

Worker prüft Quellen alle 120 Sekunden mit bis zu 15 Sekunden Zufall. Seiten lesen gespeicherte Daten und aktualisieren sichtbar alle 30 Sekunden. Manuelle Aktualisierung liest ebenfalls gespeicherte Daten.

Eine gültige Erfassung wird nach 6 Minuten veraltet. Ihr letzter Bericht bleibt mit Warnung sichtbar. Erfassungszeit ist der Empfang und die Validierung der Daten. Die Quellenzeit stammt vom Anbieter oder ist ausdrücklich als letztes Ereignisupdate gekennzeichnet; eine unveränderte Quellenzeit bedeutet allein keine veraltete Erfassung.

Jede Erfassung hat 10 Sekunden Zeitlimit, jede Antwort maximal 512 KiB. Gemini und Google Cloud verlangen jeweils validierten festen Produktkatalog und Ereignisfeed vor dem Speichern. Fehler führen zu Wartezeiten bis eine Stunde unter Beachtung lesbarer Retry-After-Werte. Fehler werden separat gespeichert und verwandeln Anbieterberichte nie in Ausfälle.

Unbekannte Statuswerte bleiben unbekannt. Fehlende Listen als nicht geliefert markiert. Zukünftige Wartung separat, kein aktueller Ausfall. Fehlendes Feedereignis belegt weder ganzen Verlauf noch unabhängig Erholung.

Tagesverlauf und Abdeckung

Verzeichnis zeigt sieben UTC-Tage, Details dreißig oder sieben. Punkte zeigen schwersten gespeicherten Tageszustand, getrennt von jetzt. Grün normal/bestandene Prüfung, gelb beeinträchtigt/erneut geprüft, rot Ausfall/bestätigter Fehler, blau laufende Wartung. Grau fehlend/unklar; Erklärung nennt Grund.

Ein halb gefüllter Punkt zeigt unvollständige Abdeckung oder einen noch laufenden Tag. Der gestrichelte Ring kennzeichnet heute. Bekannte Statusabdeckung zählt interpretierbare Aufzeichnungen über den ganzen Tag oder die bisherige Zeit heute. Dies ist Datenabdeckung, keine gemessene Verfügbarkeit.

Gespeicherte Zustände sind durch nächste Beobachtung und Aktualitätsgrenzen begrenzt: offiziell sechs Minuten, Prüfungen fünfzehn. Prüfverlauf nutzt aufeinanderfolgende Fehler-/Erholungsregeln. Erfassungsfehler zählen separat, niemals als Ausfälle. Dauer ist gespeicherter Zustand, nicht exakte Ereignisdauer. Vor erster Beobachtung bleiben Tage grau; kein vollständiger Anbieterverlauf wird importiert oder behauptet.

Regionale Beobachtungen

Unabhängige Agents prüfen GitHubs öffentliche Homepage und Metadaten eines öffentlichen Repositorys per API. IPv4 HTTPS, Zertifikat und erwarteter Inhalt werden geprüft; DNS-, Verbindungs-, TLS-, Header- und Gesamtzeiten gespeichert. Erfolgreiche Homepageprüfung bestätigt weder Anmeldung, Git noch Actions. Öffentliches API-Lesen bestätigt keine authentifizierten Vorgänge.

Resolver wird pro Knoten gezeigt: System oder Cloudflare DNS over HTTPS. Letzteres prüft nicht Systemauflösung und kann andere Zieladressen wählen. Private/spezielle Bereiche abgelehnt; Ziele fest, validierte öffentliche IP für Anfrage fixiert, keine Weiterleitungen.

Jeder Agent prüft zwei feste Verbindungskontrollen von Cloudflare und Mozilla. Mindestens eine muss bestehen, bevor Zielfehler zur Bestätigung zählen. Sonst lautet das Ergebnis „Prüfverbindung unklar“. Dieser begrenzte Verbindungstest belegt nicht die Gesundheit des Knotens oder aller Netzwerkpfade.

Prüfungen laufen alle 5 Minuten mit bis zu 15 Sekunden Zufallsverzögerung. Ein Fehler heißt „Fehler wird erneut geprüft“; zwei aufeinanderfolgende Fehler bestätigen eine fehlgeschlagene Prüfung am Knoten. Wiederherstellung nach frischem bestätigtem Fehler braucht zwei Erfolge; nach einer veralteten Lücke beginnt ein Erfolg eine neue Basis. Bestätigung erfordert Beobachtungen und Empfang mindestens 4 Minuten auseinander, ohne Lücke ab 15 Minuten. Zugriffsverweigerung, Limits, Weiterleitungen und abgelehnte Zieladressen bleiben unklar und bestätigen keinen Dienstausfall.

Beobachtungen und Heartbeats veralten nach 15 Minuten. Alte Prüfungen behalten keine aktuelle Erfolgs-/Fehlermarke. Beobachtungszeit ist Zyklusabschluss des Agents, Empfangszeit die Serverannahme. Fehlende Berichte, Erfassungsfehler und Dienstausfälle bleiben getrennt.

Geschäftsziele werden auf unabhängigen Knoten geprüft. Die Zentrale erfasst offizielle Berichte und empfängt Ergebnisse, prüft aber keine Geschäftsziele. Unverifizierte Standorte fehlen im Regionsverlauf. Ashburn, Frankfurt und Tokyo benötigen echte entfernte Knoten; Registrierung allein belegt keine Abdeckung. Standort und Netzwerk konfiguriert der Betreiber ohne automatische Verifizierung. Wir leiten weder regionale Erreichbarkeit aus globalen Berichten noch globalen Status per Knotenabstimmung oder Ausfallursachen ab.

Tatsächliche Abdeckung ansehen

Abhängigkeiten und Kausalität

Noch keine verifizierten vorgelagerten Abhängigkeiten veröffentlicht. Ein Anbieterereignis allein bestimmt weder betroffene Anwendung noch Problemursache eines Nutzers.

Kostenloser Zugriff und minimale Messung

Statusabfragen kostenlos ohne Konto. E-Mail-Benachrichtigungen geplant; diese Version versendet keine E-Mails und erfasst keine Adressen.

Wir erfassen Dienstbesuche, Quellenlinkklicks und freiwilliges Feedback mit zufälliger Kennung in sessionStorage dieses Tabs. Keine IP, E-Mail oder voller User-Agent gespeichert. Automatische Aktualisierungen zählen nicht als Besuch; bekannte Bots bestmöglich gefiltert.

Entwicklungsereignisse sind als intern markiert. Daten werden in der vom Betreiber konfigurierten Datenbank gespeichert. Automatische Aufbewahrungsbereinigung fehlt noch; öffentliche Bereitstellung erfordert eine Aufbewahrungsrichtlinie und ihre Durchsetzung.