Opsphere Neuigkeiten

Glama führt den Opsphere-Connector für operative Untersuchungen

Glama führt Opsphere — DevOps & SRE Intelligence unter io.opsphere.mcp-cursor. Eine Glama-Sitzung kann das entfernte Opsphere-Gateway über Streamable HTTP und OAuth2 erreichen, um Bugs zu untersuchen, die Release-Bereitschaft zu prüfen, Logs zu durchsuchen, Ausfälle zu triagieren, fehlgeschlagene CI zu diagnostizieren, Deployments zu prüfen und verbundene Cloud-Plattformen abzufragen. Glama markiert die Inhaberschaft als geprüft und meldet, dass OAuth in Glama funktioniert.

Der Eintrag enthält Nur-Lese-QA-Subagents. Opsphere ist standardmäßig nur lesend. Verbundene Systeme bleiben die Quelle der Nachweise. Opsphere kopiert diese Telemetrie nicht in einen anderen Speicher.

Google Analytics 4: Traffic und Conversions in operativen Untersuchungen

Opsphere fragt jetzt eine verbundene Google-Analytics-4-Property während einer operativen Untersuchung ab. Nur-Lese-Tools decken Traffic, Akquisition, Seiten, Ereignisse, Conversions, Trichter, Echtzeit und Property-Metadaten ab. Das Modul ga4 bleibt deaktiviert, bis dieser Tenant Google mit Connect Google verknüpft und ein Operator die Module google und ga4 aktiviert. Google Analytics bleibt die Quelle dieser Ergebnisse.

Wenn ga4_default_property in Admin gesetzt ist, nutzen die Tools diese Property. Makros können Traffic- und Conversion-Verschiebungen neben Deployments und Incidents stellen. Diese Darstellung behauptet nicht, ein Deployment oder ein Incident habe die Verschiebung verursacht. Opsphere ist standardmäßig nur lesend.

Google Search Console: Suchleistung in operativen Untersuchungen

Opsphere fragt jetzt eine verbundene Google-Search-Console-Property während einer operativen Untersuchung ab. Nur-Lese-Tools decken Leistung, Queries, Seiten, Trends, die Aufschlüsselung nach Gerät und Land, die URL-Prüfung und Sitemaps ab. Das Modul gsc bleibt deaktiviert, bis dieser Tenant Google mit Connect Google verknüpft und ein Operator das Modul aktiviert. Google Search Console bleibt die Quelle dieser Ergebnisse.

Wenn ein Aufruf die Site weglässt, nutzt Opsphere gsc_default_site aus Admin. Für Release- und Incident-Arbeit verbindet macro_seo_technical_diagnostic die URL-Prüfung von Search Console mit HTTP- und DNS-Checks. Opsphere ist standardmäßig nur lesend.

Google Tag Manager: Container-Konfiguration in operativen Untersuchungen

Opsphere fragt jetzt ein verbundenes Google-Tag-Manager-Konto während einer operativen Untersuchung ab. Zehn Nur-Lese-Tools decken Konten, Container, Tags, Trigger, Variablen, veröffentlichte Versionen, den Workspace-Status und Versionsdiffs ab. Das Modul gtm bleibt deaktiviert, bis dieser Tenant Google mit Connect Google verknüpft und ein Operator das Modul aktiviert. Google Tag Manager bleibt die Quelle dieser Container-Konfiguration.

Die Tag-Manager-API gibt die Container-Konfiguration wieder, nicht das Auslösen im Browser. Die Prüfung über die ganze Strecke verbindet diese Konfiguration mit macro_tracking_integrity_audit und HTTP-Checks. Opsphere ist standardmäßig nur lesend und ändert den Container nicht.

Grafana: Dashboards, Alerts und PromQL in operativen Untersuchungen

Opsphere fragt jetzt eine verbundene Grafana-Instanz während einer operativen Untersuchung ab. Zwölf Nur-Lese-Tools decken den Zustand der Organisation, Datasources, Dashboards, aktive Alerts, Annotations, PromQL über eine Grafana-Datasource und die Check-Definitionen von Synthetic Monitoring ab. Das Modul bleibt deaktiviert, bis dieser Tenant die Zugangsdaten konfiguriert. Grafana bleibt die Quelle dieser Ergebnisse.

PromQL läuft über den Grafana-Datasource-Proxy und braucht die UID der Prometheus-Datasource dieses Tenants. Es ergänzt die bestehenden direkten Prometheus-Tools. Die Synthetic-Monitoring-Tools liefern die Check-Definition, nicht historische Probe-Ergebnisse. Opsphere ist standardmäßig nur lesend und kopiert Grafana-Telemetrie nicht in einen anderen Speicher.

Noibu: E-Commerce-Fehler und Sitzungsmetriken aus Opsphere untersuchen

Opsphere vermittelt jetzt Noibu für die Untersuchung von E-Commerce-Vorfällen. Fünfzehn kuratierte Tools decken die Workspace-Verbindung und die Nur-Lese-Prüfungen ab: überwachte Shop-Domains, Prioritätsfehler, Issue-Suche einschließlich Checkout, eine Diagnose in Klartext und den Auftretensverlauf. Die Verbindung erfolgt einmal pro Workspace per OAuth. Es gibt keinen statischen API-Schlüssel, den Sie in den Chat einfügen.

Sitzungsmetriken umfassen Conversion, Bounce, Umsatz und Traffic, dazu aktuelle Sitzungen sowie Seiten-Traffic, Klicks, Scroll-Tiefe und Web Vitals. Highlight-Fenster betroffener Sitzungen sind enthalten. Session-Replay, Heatmaps, Log-Drains, Experimente und jede Rückschreibung nach Noibu bleiben in der Noibu-Konsole. Opsphere ersetzt Noibu nicht.

Das Modul ist in kostenpflichtigen Plänen verfügbar und auf Community nicht aktiviert. Kombinieren Sie es mit Storefront-Deploy-Prüfungen und mit Datadog- oder Sentry-Issue-Flows, wenn diese verbunden sind. Umsatzwirkungszahlen von Noibu bleiben Noibu-Projektionen.

Sentry: Release Health nach Sitzungen und eine ehrliche Korrektur der Projektstatistiken

Die Sentry-Integration enthält jetzt zwei Nur-Lese-Tools für Release Health. Sitzungen lassen sich nach Release gruppieren, mit Adoption im gewählten Zeitfenster, und ein einzelnes Release lässt sich für Metadaten und Sitzungsanteil öffnen. Sie nutzen dasselbe Sentry-Auth-Token, das Sie bereits konfigurieren; keine neuen Zugangsdaten und kein neuer Integration-Slug.

sentry_sessions_by_release liest die Sitzungsstatistiken der Organisation, gruppiert nach Release. sentry_release_detail liefert Metadaten und den Sitzungsanteil einer Version in diesem Fenster. Ein längeres Fenster, etwa 24 Stunden, enthält weiterhin Sitzungen älterer Releases im Projekt. Ein kurzes Fenster zeigt, wie viel des jüngsten Traffics bereits auf dem neuen Release liegt. Beides nutzt Sentry-Sitzungsstatistiken, nicht die Issue-Suche.

sentry_projects_stats meldet jetzt das Event-Volumen des Projekts. Das ist kein Release-Adoptionsdiagramm. Der vollständige operative Katalog von Opsphere umfasst 353 Tools. Das ist eine Capability-Erweiterung der bestehenden Sentry-Integration, kein neues Anbieterlogo im Hub.

Opsphere wird Teil des Santander-X-Ökosystems

Wir gehen weitere Schritte, um Opsphere mit Ökosystemen zu verbinden, die unser technologisches und unternehmerisches Wachstum begleiten können.

Opsphere ist jetzt Teil von Santander X, dem globalen Entrepreneurship-Ökosystem der Banco Santander für Start-ups, Scale-ups und Gründerinnen und Gründer.

Diese Aufnahme gibt uns Zugang zu neuen Chancen, technologischen Vorteilen, Challenges, Events und Verbindungen in der internationalen Community.

Für uns ist das eine weitere Gelegenheit, Opsphere weiter wachsen zu lassen und unsere Plattform für operative Intelligenz neuen Teams und Organisationen näherzubringen.

Xray Cloud: manuelle Jira-Tests lesen, gesteuerte Schreibzugriffe nach Freigabe

Opsphere verbindet sich mit Xray Test Management for Jira Cloud, damit Agents manuelle Test-Vorgänge und ihre Schritte lesen können. Das ist eine Qualitätssicherungsfähigkeit neben Jira. Opsphere ersetzt Xray nicht.

Zwei Tools sind lesend: xray_test_get liefert einen Test-Vorgang samt manuellen Schritten, xray_tests_search sucht Tests und Dubletten. Zwei weitere, xray_test_create und xray_test_steps_update, legen Tests an und aktualisieren Schritte, bleiben aber aus, bis der Tenant Schreibzugriffe freigibt.

Die Zugangsdaten sind Client-ID und Secret von Xray unter Jira → Apps → Xray, optional mit einer Basis-URL für die Region USA oder EU. Das Modul bleibt aus, bis ein Admin es aktiviert. Der volle Katalog umfasst 341 Tools. Community bleibt bei 62 Tools, und Xray gehört nicht zum Community-Plan.

Operativer Kontext, der über Untersuchungen hinweg erhalten bleibt

Troubleshooting sollte nicht jedes Mal bei null beginnen. Opsphere kann jetzt ein begrenztes operatives Bild der untersuchten Umgebung aufbauen und relevantes Wissen aus früheren Untersuchungen wiederverwenden, wenn es die nächste operative Frage beantwortet.

Die Plattform pflegt Beziehungen zwischen operativen Entitäten wie Accounts, Environments, Services, Repositories und Domains. Dieser Kontext wird selektiv abgerufen — nur wenn er für die aktuelle Troubleshooting-Aufgabe relevant ist — statt jedes KI-Gespräch mit einem vollständigen Infrastrukturinventar zu überladen. Operativer Kontext ist auf den jeweiligen Tenant, Account und Environment begrenzt und folgt demselben Isolationsmodell wie der Rest von Opsphere.

Frühere Untersuchungen können als strukturiertes operatives Gedächtnis gespeichert werden: betroffener Kontext, Hypothesen, Schlussfolgerungen, Evidenzreferenzen, Empfehlungen und Verifikationsinformationen. Ähnelt ein neuer Incident einem bereits untersuchten Fall, kann Opsphere die relevantesten früheren Fälle als zusätzlichen Kontext einblenden.

Die zugrunde liegende Telemetrie bleibt in den Systemen, die sie bereits besitzen. Opsphere muss kein weiteres Observability-Datastore werden: Es hält operative Beziehungen, Provenienz und Untersuchungswissen vor und fragt Live-Systeme ab, wenn aktuelle Evidenz nötig ist.

Netzwerkdiagnostik: CNAME-Abfrage und direkte Origin-Prüfungen aus Cursor

Die integrierte Netzwerkdiagnostik fragt A, AAAA und CNAME jetzt in einem einzigen dns_lookup-Aufruf über recordTypes ab, damit Sie Origin-Hostnames ohne dig zuordnen können. http_check sendet weiterhin HEAD-Requests an öffentliche URLs über Umgebungen hinweg — mit denselben Defaults.

Sie können den Origin auch direkt prüfen: eigener Host-Header, TCP/TLS zu connectHost und TLS-SNI über servername. Dieser CDN-Bypass dient der 502/520-Triage — Statuscodes und Header mit dem öffentlichen Edge vergleichen, ohne Cursor zu verlassen.

Das ist eine Capability-Erweiterung des bestehenden Community-tauglichen Diagnostikmoduls, keine neue Integration und kein Hub-Logo. Keine neuen Tool-Namen, keine Credentials. Es passt zu den integrierten Endpoint-Health- und Outage-Flows und ergänzt Cloudflare-Tools, wenn diese konfiguriert sind.

Operative Untersuchungen, die ihre Evidenz zeigen

Operative KI sollte nicht von einem Symptom direkt zu einer selbstsicheren Root-Cause-Erzählung springen. Opsphere strukturiert Untersuchungen jetzt um mehrere plausible Erklärungen und prüft sie schrittweise gegen das, was die angebundenen operativen Systeme tatsächlich liefern.

Hypothesen können Deployments, Konfiguration, Infrastruktur, Anwendungsverhalten, externe Abhängigkeiten, Networking, CDN-Verhalten und andere operative Domänen abdecken. Evidenz aus echten Tool-Aufrufen kann eine Hypothese stützen, widerlegen oder ungelöst lassen — beobachtete Fakten bleiben klar von der Inferenz getrennt.

Die Konfidenz wird aus der verfügbaren Evidenz berechnet: ihrer Qualität, unabhängigen stützenden Quellen und Widersprüchen. Wenn die Quellsysteme Zeitstempel liefern, baut Opsphere außerdem eine Untersuchungszeitlinie aus bereits gesammelter Evidenz — ohne unnötige zusätzliche Requests.

Gestützte Schlussfolgerungen und Empfehlungen können explizite Verifikationsbedingungen enthalten: was wahr werden muss, bevor ein Incident oder eine vorgeschlagene Lösung als validiert gilt. Opsphere bleibt standardmäßig read-only — es untersucht, korreliert und empfiehlt, ohne Produktion stillschweigend zu verändern. High-Level-Untersuchungen und Macros am MCP-Gateway können dasselbe strukturierte Ergebnis an Cursor, Codex und andere MCP-fähige Clients zurückgeben.

Azure: Log-Analytics-KQL-, Blob-Find- und Key-Vault-Metadaten-Tools

Die Azure-Integration umfasst jetzt vier Read-only-Daten-Tools für Incident-Triage: Log-Analytics-KQL, Blob-Schlüssel-Suche sowie Key-Vault-Geheimnamen und -Metadaten. Sie nutzen dieselbe delegierte Azure-Sitzung, mit der Sie sich bereits anmelden — keine neuen Opsphere-Secrets oder Integration-Slug.

Fragen Sie Log Analytics mit schreibgeschütztem KQL ab, wenn ein Workspace verfügbar ist. Finden Sie Blob-Schlüssel per Prefix oder exaktem Namen, ohne Inhalte herunterzuladen. Listen Sie Key-Vault-Geheimnamen und prüfen Sie Metadaten eines Secrets — niemals den Wert. Nützlich bei Daten-Incidents ohne das Azure-Portal.

Das ist eine Capability-Erweiterung der bestehenden Azure-Integration, kein neues Hub-Logo. Synapse-, Cosmos- und ACR-Daten-Tools bleiben auf der Roadmap und sind nicht Teil dieses Releases.

Fünf MCP-Tools live: Cloudflare-Cache-Purge, Datadog-Metriken, Vercel-Deploy-Logs, Traceroute und Incident-Rollup

Fünf zuvor als geplant markierte Tools sind jetzt allgemein verfügbar: Cloudflare-Cache per URL, Tag, Host oder Prefix purgen; Datadog-Metrik-Timeseries abfragen; Vercel-Deployment-Build- und Runtime-Logs lesen; Traceroute aus der Opsphere-Umgebung ausführen; und eine schreibgeschützte Incident-Timeline abrufen. Sie nutzen die Cloudflare-, Datadog- und Vercel-Credentials, die Sie bereits konfigurieren — keine neuen Secrets oder Integration-Slugs.

Cloudflare-Cache-Purge ist ein destruktiver Write und über eine Freigabe-Policy abgesichert. Das Incident-Rollup ist ein schreibgeschützter JSON-Snapshot; interaktives Outage-Triage bleibt der Macro-Workflow. Traceroute diagnostiziert den Netzwerkpfad vom Opsphere-Host.

Dieses Release schließt die Lücke zwischen API-Referenzzeilen, die noch als geplant gelten, und dem Live-Gateway. Es ist eine Capability-Erweiterung bestehender Integrationen und Plattform-Diagnostik — keine neuen Vendor-Logos im Hub.

Datadog: Synthetic-Ausführungsergebnisse und ehrliches Up/Down nach Standort

Die Datadog-Integration umfasst jetzt ein Tool, um Synthetic-Ausführungsergebnisse aufzulisten und zu prüfen — Pass oder Fail für einen benannten Test in einem Zeitfenster. Es nutzt dieselben Datadog-API- und App-Keys, die Sie bereits konfigurieren; keine neuen Credentials oder Integration-Slug.

Standort-Zusammenfassungen folgen jetzt dem letzten Ausführungsstatus pro Test, nicht dem Live- oder Paused-Config-Flag. Gibt es im Fenster keine Runs, meldet Opsphere diese Lücke statt eines falschen 100%-Uptime-Charts. Inventar und Config-Status bleiben auf der bestehenden Synthetics-Zusammenfassung — diese Ansicht ist kein Pass/Fail.

Der vollständige Opsphere-Operationskatalog erreicht 328 Tools. Das ist eine Capability-Erweiterung der bestehenden Datadog-Integration, kein neues Vendor-Logo im Hub. Wenn Datadog über Opsphere verbunden ist, sollten Agents diese Tools nutzen statt nach einer lokalen Datadog-API zu fragen.

Cloudflare Load Balancing: vier Read-only-Tools für Pools, Origins und Health Checks

Die Cloudflare-Integration umfasst jetzt vier Read-only-Load-Balancer-Tools: Inventar der Load Balancer (optionaler Zone-Filter), Pools, Origins und Steering eines Balancers, Pool-Gesundheit im Account sowie Health-Monitor-Konfiguration — Pfad, Intervall und erwartete Statuscodes. Sie nutzen denselben Cloudflare-API-Token, den Sie bereits konfigurieren; keine neuen Credentials oder Integration-Slug.

Antworten kommen als agentenfreundliche Felder, nicht als rohes Cloudflare-JSON. Leere Listen sind gültig, wenn der Account noch keine Pools oder Monitore hat — hilfreich für Edge-Traffic-Triage, Origin-Gesundheit und Steering ohne das Cloudflare-Dashboard.

Das Cloudflare-Modul hat auf der Gateway nun 54 Tools. Der vollständige Opsphere-Operationskatalog erreicht 327 Tools — eine Capability-Erweiterung der bestehenden Integration, kein neues Vendor-Logo im Hub.

Opsphere bringt operativen Kontext per MCP in Slackbot

Opsphere liefert eine eigene Slack-Integration: Aktivieren Sie das Remote-MCP-Gateway als App in Slackbot-Gesprächen, authentifizieren Sie die Verbindung und stellen Sie Fragen in natürlicher Sprache zu beliebigen Integrationen Ihres gebuchten Plans — ohne Slack zu verlassen. Die Slackbot-Oberfläche ist auf allen aktuellen Plänen verfügbar; welche Tools antworten, folgt weiterhin den verbundenen Integrationen.

Die öffentliche Website ergänzt eine vollständige Slack-Integrationsseite zu MCP-Konfiguration, Authentifizierung und Aktivierung im Chat sowie die Entdeckung über den Integrations-Hub (Alerting und DevOps & Collaboration) und das Homepage-Karussell.

Dieses Release erweitert Opsphere über Editoren und den Web-Client hinaus in den Chat, in dem Teams bereits triageieren — ein operatives Gateway, jetzt aus Slackbot erreichbar.

Opsphere liefert eine eigene Codex-Integration

Opsphere bietet jetzt eine erstklassige Integration für OpenAI Codex CLI und ChatGPT Desktop — dasselbe Remote-MCP-Gateway und dieselbe operative Tool-Oberfläche wie in Cursor, mit einem Codex-nativen Plugin, Marketplace-Installation und OAuth-Client. Ingenieure können Incidents untersuchen, Endpoint-Gesundheit prüfen, CI diagnostizieren, Integrationen konfigurieren und Connection-Hub-Arbeitskontexte öffnen, ohne die Agent-Session zu verlassen.

Die öffentliche Website ergänzt eine eigene Codex-Seite im Stil der Cursor-Core-Product-Story mit Codex-spezifischer Installations- und Skill-Führung sowie Sichtbarkeit im Integrations-Hub unter AI Tools und im Homepage-Karussell. Die Header-Navigation fasst Cursor und Codex unter Plugins zusammen, damit beide Editor-Clients einen Klick entfernt bleiben.

Dieses Release stärkt Opsphere als gemeinsame operative Schicht für KI-native Editoren: ein Gateway, geführte Skills und read-only Investigation Flows — ob Teams in Cursor oder in Codex arbeiten.

AWS: Bedrock-Agents und Action-Group-Lambdas diagnostizieren

Die AWS-Integration ergänzt zwei schreibgeschützte Diagnose-Tools für Bedrock Agents mit derselben SSO- oder IAM-Sitzung wie Ihre übrigen aws_*-Tools — keine neuen Opsphere-Geheimnisse. Fokus ist operative Diagnose (Status, Aliase, Action Groups, IAM, Knowledge Bases und Findings), nicht das Produkt Agent Core.

aws_bedrock_agent_diagnose liefert in einem Aufruf Agent-Gesundheit, IAM-Warnungen, KB-Status, verknüpfte Lambdas und einen Beziehungsgraphen. aws_lambda_agent_diagnose vertieft Action-Group-Lambdas mit Konfiguration, IAM-Richtlinien und CloudWatch-Fehlersignalen (Umgebungsvariablen redigiert). Der geführte Prompt investigate-bedrock-agent führt denselben Read-only-Ablauf im Web-Chat und in MCP-Playbooks aus.

Das erweitert die bestehende AWS-Integration — kein neues Anbieter-Chip im Hub. Der vollständige Opsphere-Gateway-Katalog umfasst 318 operative Tools.

AWS: Athena-, S3-Find-, DynamoDB-Query- und Aurora-Data-API-Tools

Die AWS-Integration umfasst fünf zusätzliche schreibgeschützte Tools für Datenuntersuchungen: Athena-SQL, S3-Objektsuche per Prefix oder Key, DynamoDB Describe und Query (kein Scan) sowie Aurora-SQL über die RDS Data API. Sie nutzen dieselbe SSO- oder IAM-Sitzung — keine neuen Opsphere-Credentials; DB-Geheimnisse bleiben in Ihrem Secrets Manager.

Fragen Sie Athena ab, wenn Workgroup oder S3-Ergebnisort verfügbar sind. Finden Sie S3-Keys ohne Download. Beschreiben Sie DynamoDB-Schlüssel und -Indizes, dann Query per Primärschlüssel. Führen Sie schreibgeschütztes SQL auf Aurora per HTTPS mit Cluster- und Secret-ARN aus — nützlich bei Datenvorfällen ohne AWS-Konsole.

Das ist eine Erweiterung der bestehenden AWS-Integration, kein neues Hub-Logo. Der vollständige Opsphere-Gateway-Katalog umfasst 312 operative Tools.

Cloudflare: 14 neue Read-only-Tools für Workers, Logpush, Snippets und KV

Die Cloudflare-Integration umfasst jetzt 14 zusätzliche Read-only-Tools für tiefe Edge-Operationen — Worker-Skript-Inventar, Deployment-Historie, Custom Domains, Logpush-Jobs, Zone-Snippets, Account Rules Lists, KV-Namespaces und Zone-Einstellungen. Sie nutzen denselben Cloudflare-API-Token, den Sie bereits konfigurieren; keine neuen Credentials oder Integration-Slug.

Listen Sie Worker-Skripte, Deployments und Custom Domains vom Account auf. Prüfen Sie Logpush-Jobs und Zone-Snippet-Regeln neben den bestehenden DNS- und WAF-Tools. Lesen Sie Account Rules Lists und KV-Namespaces ohne das Cloudflare-Dashboard — hilfreich für Edge-Incident-Triage, WAF-Listen-Audits und Terragrunt-verwaltete Zonen.

Das Cloudflare-Modul hat auf der Gateway nun 49 Tools. Der vollständige Opsphere-Operationskatalog erreicht 307 Tools — eine Capability-Erweiterung der bestehenden Integration, kein neues Vendor-Logo im Hub.

Connection Hub: ein Cursor-Login für jeden Kunden-Workspace

Berater, Agenturen und Plattform-Teams betreiben oft getrennte Opsphere-Tenants pro Kunde — und das Wechseln zwischen IDE-Logins unterbricht den Flow bei Incidents. Connection Hub ist eine eigene Opsphere-Plattformfunktion, keine Vendor-Integration: Es verknüpft mehrere Kunden-Workspaces mit einer Cursor-Session per OAuth, damit Sie im selben IDE bleiben, während sich der operative Kontext ändert.

Verknüpfen Sie Kunden-Tenants mit ops_account_link_start, öffnen Sie einen serverseitigen Arbeitskontext mit ops_context_open und führen Sie operative Tools mit context_id aus. Das Gateway löst Credentials serverseitig auf — nichts Sensibles landet in der IDE-Konfiguration. Plugin-Skills link-account und open-work-context leiten das Onboarding; MCP-Ressourcen opsphere://hub/connections und opsphere://hub/active-context geben Agenten den Verbindungsstatus.

Hub-Installationen können keine Integrationen konfigurieren oder operative Tools ohne aktiven Arbeitskontext ausführen. Grants werden at rest verschlüsselt. Das Release fügt fünf Broker-Control-Plane-Tools zum Gateway-Katalog hinzu; die Cursor-Integrationsseite beschreibt Connection Hub nun neben dem bestehenden offiziellen Plugin-Workflow.

Algolia-Integration unterstützt jetzt Applications pro Umgebung über Cloud Catalog

Die Opsphere-Algolia-Integration ordnet jetzt jeder Cloud-Catalog-Umgebung — dev, staging, Produktion oder Ihre eigenen Katalog-Slugs — eine eigene Algolia-Application zu. Konfigurieren Sie Application IDs, Standard-Indizes und eingeschränkte Search-API-Keys pro Umgebung im Admin-Cloud-Catalog; MCP-Search-API-Tools akzeptieren optionales env, sodass Anfragen wie „Indizes in Staging auflisten“ die richtige Application statt Produktion auflösen. Globale Cluster-Diagnostik bleibt ohne Credentials.

Enterprise-Storefronts betreiben oft getrennte Algolia-Applications pro Tier. Dieses Update bringt Opsphere mit diesem Modell in Einklang und verhindert Credential-Leaks zwischen Umgebungen. Legacy-Konfiguration mit einer globalen Application ID und API-Key bleibt für Single-App-Tenants unterstützt.

Integrationsdetail und API-Referenz auf der Website beschreiben jetzt die Multi-Environment-Einrichtung neben den bestehenden Such- und Index-Triage-Workflows.

Intelligentere operative Speicher-Abfrage und Admin-GDPR-Steuerung

Opspheres operative Speicherung liefert MCP-Agenten destillierten Kontext aus vergangenen Incidents, Repository-Notizen, Session-Zusammenfassungen und leichten Entscheidungen — damit Untersuchungen mit Präzedenz starten statt denselben Boden erneut abzudecken. Speicher ergänzt Live-Observability und Infrastruktur-Tools; Agenten verifizieren den aktuellen Zustand weiterhin mit Datadog, Kubernetes, Vercel und anderen operativen Quellen.

Dieses Release verbessert die Abfrage: Volltextsuche mit titelgewichtetem Ranking, automatische mehrstufige Query-Expansion für Ops-Vokabular und heuristisches Ranking, das aktive Incidents, jüngste Entscheidungen und häufig genutzte Repositories priorisiert. Der Ansatz ist auf kurze operative Korpora ausgelegt — schnelle Abfrage ohne Embedding-Latenz oder zusätzliche Suchinfrastruktur.

Tenant-Admins erhalten zudem Governance-Kontrollen im Admin-Portal: Speichereinträge listen und filtern, veraltete Einträge mit Begründung invalidieren und GDPR-Benutzer-Purge mit Dry-Run-Vorschau ausführen — mit Audit-Trail für Purge-Aktionen. Self-Service-MCP-Tools bleiben für Nutzer verfügbar, die Löschung ohne Admin-Eingriff benötigen.

Railway-Integration bringt PaaS-Deploy- und Runtime-Triage nach Opsphere

Opsphere integriert jetzt Railway und erweitert die operative Sichtbarkeit auf PaaS-Projekte, Deployments und Runtime-Gesundheit. Teams können Projektstatus über Umgebungen und Services prüfen, jüngste Deployments einsehen, Build- und Runtime-Logs abrufen und read-only Incident-Diagnose für korrelierte Hypothesen ausführen — alles im selben operativen Workspace wie für Vercel, Kubernetes, Datadog und AWS.

Railway-Deploy- und Log-Signale mit Infrastruktur- und Observability-Daten zu verbinden, hilft Ingenieuren zu klären, ob ein Ausfall mit einem fehlgeschlagenen Release, einem Runtime-Fehlermuster oder einer Upstream-Abhängigkeit begann — ohne bei jeder Untersuchung zwischen Railway, Monitoring-Tools und Incident-Chat zu wechseln.

Damit wächst Opsphere weiter als einheitliche operative Schicht, die PaaS-Triage mit Delivery-, Observability- und Infrastruktur-Signalen in einer konsistenten read-only Erfahrung korreliert.

Algolia-Integration bringt Such- und Index-Gesundheit in den operativen Kontext

Opsphere integriert jetzt Algolia und erweitert die operative Sichtbarkeit auf Suchinfrastruktur und Index-Gesundheit. Teams können den globalen Cluster-Status und die Incident-Historie ohne Credentials prüfen, Indizes mit Eintragszahlen und Build-Metadaten listen, Suchanfragen reproduzieren, indexierte Datensätze per objectID validieren und jüngste API-Aktivität einsehen — alles im selben read-only operativen Workspace.

Algolia-Indexdaten mit Deployments, CMS-Änderungen und Storefront-Observability zu verbinden, hilft Ingenieuren zu klären, ob Suchprobleme von veralteten Datensätzen, Ranking-Einstellungen oder Upstream-Incidents stammen — ohne bei jeder Untersuchung zwischen Algolia, Contentful CMS, Datadog und Sentry zu wechseln.

Damit wächst Opsphere weiter als einheitliche operative Schicht, die Such-Triage mit Infrastruktur-, Observability- und Delivery-Signalen in einer konsistenten read-only Erfahrung korreliert.

Opsphere bereitet den Start seines offiziellen Plugins für Codex vor

Opsphere finalisiert den bevorstehenden Launch seines offiziellen Plugins für Codex und Cursor — entwickelt, um operative Intelligenz und DevOps-Diagnostik direkt in die Entwicklungsumgebung und Chat-Oberfläche zu bringen. Auf einer Remote-MCP-Architektur (Model Context Protocol) können Ingenieur- und SRE-Teams Incidents untersuchen, Metriken prüfen, Deployments analysieren und Netzwerkdiagnosen auf Plattformen wie Datadog, Vercel, GitHub, AWS, Sentry oder Jira durchführen, ohne den Editor zu verlassen oder den Kontext zu wechseln.

Die Opsphere-Integration in Codex und Cursor beseitigt die Reibung zwischen Code schreiben und Produktionsanalyse. Über geführte Flows in natürlicher Sprache führen Teams Endpoint-Health-Checks, Ausfall-Triage und CI/CD-Pipeline-Fehleranalysen in Sekunden durch — alles unter einem Read-only-Berechtigungsmodell und OAuth2-Authentifizierung, die Zugangsdaten vollständig auf dem Remote-Gateway schützt.

Das Plugin wird in den kommenden Tagen öffentlich verfügbar sein und eine kostenlose Testphase mit dem Community-Plan bieten. Damit festigt Opsphere seine Rolle als zentrale Schicht für operativen Kontext und Investigation für KI-Agenten.

PagerDuty und Prometheus erweitern Incident Response und Infrastruktur-Sichtbarkeit

Opsphere integriert jetzt PagerDuty und Prometheus und liefert mehr operativen Kontext für Infrastruktur-Monitoring und Incident Response. Teams sehen aktive Incidents, Services und Timelines in PagerDuty und können Prometheus-Metriken, Alerts, Regeln, Scrape Targets und PromQL-Daten in derselben Oberfläche abfragen.

Metriken und Incident-Informationen zusammenzuführen, beschleunigt Untersuchungen — ohne ständiges Wechseln zwischen Monitoring- und Incident-Management-Plattformen. So gelangt man schneller zu den Fakten in Produktionsumgebungen.

Damit wächst Opsphere weiter als zentrale operative Schicht, die Cloud-Plattformen, Observability, CI/CD und Incident-Management-Tools in einer read-only Erfahrung verbindet.

GitLab und SonarQube stärken den Software-Delivery-Workflow

Opsphere bietet jetzt native Integrationen mit GitLab und SonarQube und erweitert die operative Sichtbarkeit über den Software-Delivery-Lifecycle. Entwicklungsteams greifen auf GitLab-Projekte, Merge Requests, Pipelines und Deployment-Historie zu und sehen SonarQube Quality Gates, Code-Metriken, Security Hotspots und New-Code-Analysen im selben operativen Workspace.

CI/CD-Aktivität und Code-Qualität zusammenzubringen, hilft schnell zu verstehen, was sich geändert hat, ob ein Quality Gate bestanden wurde und wie aktuelle Releases zur Produktion stehen. Weniger Plattformwechsel bei Untersuchungen, mehr Entwicklungskontext neben Infrastruktur- und Observability-Daten.

Diese Integrationen erweitern weiter die einheitliche Opsphere-Plattform und verbinden Software Delivery mit operativer Intelligenz in einer konsistenten read-only Erfahrung.