Opsphere News

Glama lists the Opsphere connector for operational investigations

Glama lists Opsphere — DevOps & SRE Intelligence under io.opsphere.mcp-cursor. A Glama session can reach the remote Opsphere gateway over Streamable HTTP and OAuth2 to investigate bugs, assess release readiness, search logs, triage outages, diagnose failed CI, check deployments, and query connected cloud platforms. Glama marks ownership as verified and reports that OAuth works in Glama.

The listing includes read-only QA subagents. Opsphere is read-only by default. Connected systems remain the source of the evidence. Opsphere does not copy that telemetry into another store.

Google Analytics 4: traffic and conversions in operational investigations

Opsphere now queries a connected Google Analytics 4 property during an operational investigation. Read-only tools cover traffic, acquisition, pages, events, conversions, funnels, realtime, and property metadata. The ga4 module stays disabled until that tenant links Google with Connect Google and an operator enables the google and ga4 modules. Google Analytics remains the source of those results.

When ga4_default_property is set in Admin, tools use that property. Macros can place traffic and conversion shifts next to deploys and incidents. That narrative does not claim a deploy or an incident caused the shift. Opsphere is read-only by default.

Google Search Console: search performance in operational investigations

Opsphere now queries a connected Google Search Console property during an operational investigation. Read-only tools cover performance, queries, pages, trends, device and country breakdowns, URL inspection, and sitemaps. The gsc module stays disabled until that tenant links Google with Connect Google and an operator enables the module. Google Search Console remains the source of those results.

When a call omits the site, Opsphere uses gsc_default_site from Admin. For release and incident work, macro_seo_technical_diagnostic pairs Search Console URL inspection with HTTP and DNS checks. Opsphere is read-only by default.

Google Tag Manager: container configuration in operational investigations

Opsphere now queries a connected Google Tag Manager account during an operational investigation. Ten read-only tools cover accounts, containers, tags, triggers, variables, published versions, workspace status, and version diffs. The gtm module stays disabled until that tenant links Google with Connect Google and an operator enables the module. Google Tag Manager remains the source of that container configuration.

The Tag Manager API reflects container configuration, not live browser firing. End-to-end validation pairs that configuration with macro_tracking_integrity_audit and HTTP checks. Opsphere is read-only by default and does not change the container.

Grafana: dashboards, alerts, and PromQL in operational investigations

Opsphere now queries a connected Grafana instance during an operational investigation. Twelve read-only tools cover organization health, datasources, dashboards, firing alerts, annotations, PromQL through a Grafana datasource, and Synthetic Monitoring check definitions. The module stays disabled until that tenant configures credentials. Grafana remains the source of those results.

PromQL runs through the Grafana datasource proxy and needs the Prometheus datasource UID for that tenant. It complements the existing direct Prometheus tools. Synthetic Monitoring tools return the check definition, not historical probe results. Opsphere is read-only by default and does not copy Grafana telemetry into another store.

Noibu: investigate ecommerce errors and session metrics from Opsphere

Opsphere now brokers Noibu for ecommerce issue investigation. Fifteen curated tools cover the workspace connection and the read-only checks: monitored storefront domains, priority errors, issue search including checkout, a plain-language diagnosis, and occurrence trends. You connect once per workspace with OAuth. There is no static API key to paste into chat.

Session metrics include conversion, bounce, revenue, and traffic, plus recent sessions and page-level traffic, clicks, scroll depth, and web vitals. Highlight windows for affected sessions are included. Session replay, heatmaps, log drains, experiments, and any write back to Noibu stay on the Noibu console. Opsphere does not replace Noibu.

The module is available on paid plans and is not enabled on Community. Pair it with storefront deploy checks and with Datadog or Sentry issue flows when those are connected. Revenue-impact figures from Noibu remain Noibu projections.

Sentry: release health by session, and an honest project-stats fix

The Sentry integration now includes two read-only tools for Release Health. Session counts can be grouped by release, with adoption in the selected time window, and a single release can be opened for its metadata and session share. They use the same Sentry auth token you already configure; no new credentials or integration slug.

sentry_sessions_by_release reads organization session stats grouped by release. sentry_release_detail returns metadata and session share for one version in that window. A longer window, such as 24 hours, still includes sessions from older releases on the project. A short window shows how much recent traffic is already on the new release. Both use Sentry session stats, not issue search.

sentry_projects_stats now reports project event volume. It is not a release-adoption chart. The full Opsphere operational catalog reaches 353 tools. This is a capability expansion on the existing Sentry integration, not a new vendor logo on the hub.

Opsphere joins the Santander X ecosystem

We keep taking steps to connect Opsphere with ecosystems that can support our technological and business growth.

Opsphere is now part of Santander X, Banco Santander's global entrepreneurship ecosystem for startups, scaleups, and founders.

Joining gives us access to new opportunities, technology benefits, challenges, events, and connections within its international community.

For us, it is another chance to keep growing Opsphere and bring our operational intelligence platform to new teams and organizations.

Xray Cloud: read Jira manual tests, with governed writes when you enable them

Opsphere now connects to Xray Test Management for Jira Cloud so agents can read manual Test issues and their steps. This is a quality-assurance capability alongside Jira. Opsphere does not replace Xray.

Two tools stay read-only: xray_test_get returns a Test issue and its manual steps, and xray_tests_search looks up tests and duplicates. Two more, xray_test_create and xray_test_steps_update, can create tests and update steps, but they stay off until the tenant enables writes.

Credentials are the Xray client id and secret from Jira → Apps → Xray, with an optional base URL for the US or EU region. The module stays off until an admin enables it. The full catalog reaches 341 tools. Community stays at 62 tools, and Xray is not part of the Community plan.

Operational context that carries across investigations

Troubleshooting should not start from zero every time. Opsphere can now build a scoped operational picture of the environment being investigated and reuse relevant knowledge from previous investigations when it can help answer the next operational question.

The platform maintains relationships between operational entities such as accounts, environments, services, repositories and domains. This context is retrieved selectively — only when relevant to the current troubleshooting task — rather than dumping an entire infrastructure inventory into every AI conversation. Operational context is scoped to the relevant tenant, account and environment, preserving the same isolation model used across Opsphere.

Previous investigations can be stored as structured operational memory containing the affected context, hypotheses, conclusions, evidence references, recommendations and verification information. When a new incident resembles something investigated before, Opsphere can surface the most relevant previous cases as additional context.

The underlying telemetry remains in the systems that already own it. Opsphere does not need to become another observability datastore: it keeps operational relationships, provenance and investigation knowledge while querying live systems when current evidence is required.

Network diagnostics: CNAME lookup and direct origin probes from Cursor

Built-in network diagnostics now query A, AAAA, and CNAME in a single dns_lookup call via recordTypes, so you can map origin hostnames without dig. http_check still sends HEAD requests to public URLs across environments with the same defaults.

You can also probe the origin directly: set a custom Host header, open TCP/TLS to connectHost, and control TLS SNI with servername. That CDN bypass is for 502/520 triage — compare status codes and headers against the public edge without leaving Cursor.

This is a capability expansion of the existing Community-friendly diagnostics module, not a new integration or hub logo. No new tool names and no credentials. It works with built-in endpoint-health and outage flows, and pairs with Cloudflare tools when they are configured.

Operational investigations that show their evidence

Operational AI should not jump from a symptom to a confident root-cause story. Opsphere now structures investigations around multiple possible explanations and progressively tests them against what the connected operational systems actually report.

Hypotheses can cover deployments, configuration, infrastructure, application behavior, external dependencies, networking, CDN behavior and other operational domains. Evidence collected from real tool calls can support, reject or leave a hypothesis unresolved, while observed facts remain clearly separated from inference.

Confidence is calculated from the available evidence, including its quality, independent supporting sources and contradictions. When the underlying systems provide timestamps, Opsphere also builds an investigation timeline from the evidence already collected, without making unnecessary additional requests.

Supported conclusions and recommendations can include explicit verification conditions: what should become true before an issue or proposed resolution is considered validated. Opsphere remains read-only by default — it investigates, correlates and recommends without silently changing production. High-level investigations and macros on the MCP gateway can return the same structured result to Cursor, Codex and other MCP-compatible clients.

Azure: Log Analytics KQL, Blob find, and Key Vault metadata tools

The Azure integration now includes four read-only data tools for incident triage: Log Analytics KQL, Blob key discovery, and Key Vault secret names and metadata. They use the same delegated Azure session you already sign in with — no new Opsphere secrets or integration slug.

Query Log Analytics with read-only KQL when a workspace is available. Find blob keys by prefix or exact name without downloading bodies. List Key Vault secret names and inspect one secret’s metadata — never the secret value. Useful during data incidents without opening the Azure portal.

This is a capability expansion on the existing Azure integration, not a new hub logo. Synapse, Cosmos, and ACR data tools remain on the roadmap and are not part of this release.

Five MCP tools now live: Cloudflare cache purge, Datadog metrics, Vercel deploy logs, traceroute, incident rollup

Five tools previously marked as planned are now generally available: purge Cloudflare cache by URL, tag, host, or prefix; query Datadog metrics timeseries; read Vercel deployment build and runtime logs; run traceroute from the Opsphere environment; and fetch a read-only incident timeline. They use the Cloudflare, Datadog, and Vercel credentials you already configure — no new secrets or integration slugs.

Cloudflare cache purge is a destructive write, gated by an approval policy. The incident rollup is a read-only JSON timeline snapshot; live multi-step outage triage remains the dedicated macro workflow. Traceroute diagnoses the network path from the Opsphere host.

This shipment closes the gap between API reference rows still labelled planned and the live gateway. It is a capability expansion on existing integrations and platform diagnostics — not new vendor logos on the hub.

Datadog: Synthetic execution results and honest up/down by location

The Datadog integration now includes a tool to list and inspect Synthetic execution results — pass or fail for a named test over a time window. It uses the same Datadog API and App keys you already configure; no new credentials or integration slug.

Location summaries now follow the latest execution status per test, not the live or paused config flag. When there are no runs in the window, Opsphere reports that gap instead of a false 100% uptime chart. Inventory and config status stay on the existing Synthetics summary — that view is not pass/fail.

The full Opsphere operational catalog reaches 328 tools. This is a capability expansion on the existing Datadog integration, not a new vendor logo on the hub. When Datadog is connected through Opsphere, agents should use these tools rather than asking for a local Datadog API.

Cloudflare Load Balancing: four read-only tools for pools, origins, and health checks

The Cloudflare integration now includes four read-only Load Balancer tools: inventory load balancers (optional zone filter), inspect one balancer’s pools, origins, and steering, list pool health across the account, and read health-monitor configuration — path, interval, and expected status codes. They use the same Cloudflare API token you already configure; no new credentials or integration slug.

Responses are mapped into agent-friendly fields rather than raw Cloudflare JSON. Empty lists are valid when the account has no pools or monitors yet — useful for edge traffic triage, origin health, and steering checks without opening the Cloudflare dashboard.

The Cloudflare module now totals 54 tools on the gateway. The full Opsphere operational catalog reaches 327 tools — a capability expansion on the existing integration, not a new vendor logo on the hub.

Opsphere brings operational context into Slackbot via MCP

Opsphere now ships a dedicated Slack integration: activate the remote MCP gateway as an app in Slackbot conversations, authenticate the connection, and ask natural-language questions about any integrations configured on your hired plan — without leaving Slack. The Slackbot surface is available on all current plans; which tools answer still follows the integrations you have connected.

The public site adds a full Slack integration page covering MCP configuration, authentication, and in-chat activation, plus discovery from the integrations hub under Alerting and DevOps & Collaboration, and the homepage integrations carousel.

This release extends Opsphere beyond editors and the web client into the chat where teams already triage work — one operational gateway, now reachable from Slackbot.

Opsphere ships a dedicated Codex integration

Opsphere now has a first-class Codex integration for OpenAI Codex CLI and ChatGPT desktop — the same remote MCP gateway and operational tool surface teams already use in Cursor, with a Codex-native plugin, marketplace install path, and OAuth client. Engineers can investigate incidents, check endpoint health, diagnose CI, configure integrations, and open Connection Hub work contexts without leaving the agent session.

The public site adds a dedicated Codex page that mirrors the Cursor core-product story with Codex-accurate install and skill guidance, plus discovery from the integrations hub under AI tools and the homepage integrations carousel. Header navigation groups Cursor and Codex under Plugins so both editor clients stay one click away.

This release reinforces Opsphere as the shared operational layer for AI-native editors: one gateway, guided skills, and read-only investigation flows — whether teams work in Cursor or Codex.

AWS: diagnose Bedrock Agents and action-group Lambdas

The AWS integration adds two read-only Bedrock Agent diagnostic tools that use the same SSO or IAM session as your other aws_* tools — no new Opsphere secrets. Focus is operational diagnosis for Bedrock Agents (status, aliases, action groups, IAM, knowledge bases, and findings), not Agent Core product marketing.

aws_bedrock_agent_diagnose returns agent health, IAM warnings, KB status, linked Lambdas, and a relationship graph in one call. aws_lambda_agent_diagnose drills into action-group Lambdas with config, IAM policies, and CloudWatch error signals (environment values redacted). The guided prompt investigate-bedrock-agent runs the same read-only flow in web chat and MCP playbooks.

This extends the existing AWS integration — no new vendor chip on the hub. The full Opsphere gateway catalog reaches 318 operational tools.

AWS: Athena, S3 find, DynamoDB query, and Aurora Data API tools

The AWS integration now includes five additional read-only tools for data-plane investigation: Athena SQL, S3 object discovery by prefix or key, DynamoDB table describe and Query (no Scan), and Aurora SQL via the RDS Data API. They use the same SSO or IAM session you already log in with — no new Opsphere credentials, and database secrets stay in your own Secrets Manager.

Query Athena when a workgroup or S3 result location is available. Find S3 keys without downloading bodies. Describe DynamoDB keys and indexes, then Query by primary key. Run read-only SQL on Aurora over HTTPS with your cluster and secret ARNs — useful during data incidents without opening the AWS console.

This is a capability expansion on the existing AWS integration, not a new hub logo. The full Opsphere gateway catalog reaches 312 operational tools.

Cloudflare: 14 new read-only tools for Workers, Logpush, Snippets, and KV

The Cloudflare integration now includes 14 additional read-only tools for deep edge operations — Workers script inventory, deployment history, custom domains, Logpush jobs, zone Snippets, account Rules Lists, KV namespaces, and zone settings. They use the same Cloudflare API token you already configure; no new credentials or integration slug.

List Worker scripts, deployments, and custom domains from the account. Inspect Logpush jobs and zone Snippet rules alongside existing DNS and WAF tools. Read account Rules Lists and KV namespaces without opening the Cloudflare dashboard — useful for edge incident triage, WAF list audits, and Terragrunt-managed zones.

The Cloudflare module now totals 49 tools on the gateway. The full Opsphere operational catalog reaches 307 tools — a capability expansion on the existing integration, not a new vendor logo on the hub.

Connection Hub: one Cursor login for every client workspace

Consultants, agencies, and platform teams often run separate Opsphere tenants per client — and switching between IDE logins breaks flow during incidents. Connection Hub is a first-party Opsphere platform capability, not a vendor integration: it links multiple client workspaces to one Cursor session through OAuth so you stay in the same IDE while changing operational context.

Link client tenants with ops_account_link_start, open a server-side work context with ops_context_open, and run operational tools scoped by context_id. The gateway resolves credentials server-side — nothing sensitive lands in IDE configuration. Plugin skills link-account and open-work-context guide onboarding; MCP resources opsphere://hub/connections and opsphere://hub/active-context expose connection state to agents.

Hub installations cannot configure integrations or run operational tools without an active work context. Grants are encrypted at rest. The release adds five broker control-plane tools to the gateway catalog; Cursor integration copy on the site now describes Connection Hub alongside the existing official plugin workflow.

Algolia integration now supports per-environment Applications via Cloud Catalog

Opsphere's Algolia integration now maps each Cloud Catalog environment — dev, staging, production, or your own catalog slugs — to its own Algolia Application. Configure Application IDs, default indexes, and restricted Search API keys per environment in admin Cloud Catalog; MCP Search API tools accept optional env so requests like "list indexes in staging" resolve the correct Application instead of production. Global cluster diagnostics remain credential-free.

Enterprise storefronts often run separate Algolia Applications per tier. This update aligns Opsphere with that model and prevents cross-environment credential leakage. Legacy single Application ID and API key configuration remains supported for single-app tenants.

Integration detail and API reference copy on the site now describe multi-environment setup alongside the existing search and index triage workflows.

Smarter operational memory retrieval and admin GDPR controls

Opsphere operational memory gives MCP agents distilled context from past incidents, repository notes, session summaries, and lightweight decisions — so investigations start with precedent instead of repeating the same ground. Memory complements live observability and infrastructure tools; agents still verify current state with Datadog, Kubernetes, Vercel, and other operational sources.

This release improves how memory is retrieved: full-text search with title-weighted ranking, automatic multi-pass query expansion for operational vocabulary, and heuristic ranking that prioritizes active incidents, recent decisions, and frequently used repositories. The approach is tuned for short operational corpora — fast retrieval without embedding latency or extra search infrastructure.

Tenant admins also gain governance controls in the admin portal: list and filter memory items, invalidate stale entries with a reason, and run GDPR user purge with dry-run preview — with audit trail for purge actions. Self-service MCP tools remain available for users who need erasure without admin intervention.

Railway integration adds PaaS deploy and runtime triage to Opsphere

Opsphere now integrates with Railway, extending operational visibility into PaaS projects, deployments, and runtime health. Teams can review project status across environments and services, inspect recent deployments, pull build and runtime logs, and run read-only incident diagnosis for correlated hypotheses — all from the same operational workspace used for Vercel, Kubernetes, Datadog, and AWS.

Connecting Railway deploy and log signals with infrastructure and observability data helps engineers determine whether an outage started with a failed release, a runtime error pattern, or an upstream dependency — without switching between Railway, monitoring tools, and incident chat during every investigation.

This addition continues expanding Opsphere as a unified operational layer, helping teams correlate PaaS triage with delivery, observability, and infrastructure signals through a consistent read-only experience.

Algolia integration brings search and index health into operational context

Opsphere now integrates with Algolia, extending operational visibility into search infrastructure and index health. Teams can check global cluster status and incident history without credentials, list indices with entry counts and build metadata, reproduce search queries, validate indexed records by objectID, and review recent API activity — all from the same read-only operational workspace.

Connecting Algolia index data with deploys, CMS changes, and storefront observability helps engineers determine whether search issues stem from stale records, ranking settings, or upstream incidents — without bouncing between Algolia, Contentful CMS, Datadog, and Sentry during every investigation.

This addition continues expanding Opsphere as a unified operational layer, helping teams correlate search triage with infrastructure, observability, and delivery signals through a consistent read-only experience.

Opsphere prepares launch of its official plugin for Codex

Opsphere is finalizing the imminent launch of its official plugin for Codex and Cursor, designed to bring operational intelligence and DevOps diagnostics directly into the development environment and chat interface. Built on a remote MCP (Model Context Protocol) architecture, the plugin will let engineers and SRE teams investigate incidents, review metrics, analyze deployments, and run network diagnostics across platforms such as Datadog, Vercel, GitHub, AWS, Sentry, and Jira — without leaving their editor or switching context.

Opsphere's integration in Codex and Cursor removes the friction between writing code and analyzing production. Through natural-language guided flows, teams can perform endpoint health checks, outage triage, and CI/CD pipeline failure analysis in seconds, all under a read-only permission model and OAuth2 authentication that keeps credentials fully protected on the remote gateway.

The plugin will be publicly available in the coming days and will include a free trial with the Community plan, establishing Opsphere as the centralized operational context and investigation layer for AI agents.

PagerDuty and Prometheus expand incident response and infrastructure visibility

Opsphere now integrates with PagerDuty and Prometheus, adding more operational context for infrastructure monitoring and incident response. Teams can consult active incidents, services and incident timelines from PagerDuty while also querying Prometheus metrics, alerts, rules, scrape targets and PromQL data from the same interface.

Combining infrastructure metrics with incident information allows engineers to investigate operational issues more efficiently without constantly moving between monitoring and incident management platforms. The result is faster access to the information required to understand what is happening across production environments.

With these additions, Opsphere continues growing as a central operational layer that connects cloud platforms, observability, CI/CD and incident management tools into a single read-only operational experience.

GitLab and SonarQube strengthen the software delivery workflow

Opsphere now includes native integrations with GitLab and SonarQube, extending operational visibility across the software delivery lifecycle. Development teams can access GitLab projects, merge requests, pipelines and deployment history, while also consulting SonarQube quality gates, code metrics, security hotspots and new-code analysis from the same operational workspace.

By bringing CI/CD activity together with code quality information, engineers can quickly understand what changed, whether a quality gate passed and how recent deliveries relate to production operations. This reduces the need to switch between multiple platforms during investigations and provides valuable development context alongside infrastructure and observability data.

These integrations continue expanding Opsphere's unified operational platform, helping DevOps and platform engineering teams connect software delivery with operational intelligence through a consistent, read-only experience.