# Opsphere > Operational intelligence platform for DevOps, SRE, and cloud operations teams. ## Core product - [Platform](https://opsphere.io/platform): The operational intelligence layer for DevOps, SRE and platform engineering teams, and the parent hub for Operational Investigations and Operational Context. Opsphere connects the cloud, Kubernetes, observability, deployment, code and edge systems teams already use through MCP; queries and correlates current operational evidence from the systems that own it; supports evidence-backed investigations with hypotheses, calculated confidence, timelines and verification conditions; and maintains reusable operational context (operational knowledge graph, investigation memory). Read-only by default, tenant and environment scoped. It does not ingest or centralize telemetry and does not replace the observability or infrastructure systems that own the underlying data. - [Operational Investigations](https://opsphere.io/platform/investigations): First-party platform capability, not an integration. Opsphere structures operational investigations around multiple possible causes and tests them against evidence from the systems you already use. It keeps facts separate from inference, evaluates supporting and contradicting evidence, reports calculated confidence as HIGH/MEDIUM/LOW, builds a timeline when source timestamps exist, and defines explicit verification conditions. Read-only by default, tenant isolated, environment scoped. - [Operational Context](https://opsphere.io/platform/operational-context): First-party platform capability, not an integration. Opsphere maintains a lightweight operational knowledge graph of relationships (accounts, environments, services, repositories, domains) with provenance, plus investigation memory that preserves structured summaries of previous investigations. Similar incident matching surfaces relevant past cases. Context is scoped by tenant, account and environment, and the underlying logs, metrics, traces, code and infrastructure remain in the systems that already own them. - [MCP Operational Gateway](https://opsphere.io/platform/mcp-operational-gateway): First-party platform reference, not an integration. Explains how Opsphere exposes an operational intelligence layer through MCP rather than being a generic MCP server. A generic MCP server makes individual APIs callable; Opsphere adds a layer behind them: atomic tools answer direct questions about one system, while high-level workflows coordinate multiple checks and return a structured investigation (hypotheses, evidence, calculated confidence, timeline, verification, findings, recommendations). High-level workflows can use shared Operational Context maintained independently of the AI client; atomic tools stay focused on individual systems, and Opsphere does not automatically load context into every call. Output is machine-readable. Reachable from Cursor, Codex, Claude / Claude Code and other MCP-compatible clients. Read-only by default, tenant isolated, environment scoped; source systems remain authoritative. - [Product Facts](https://opsphere.io/product-facts): Canonical, machine-readable "What is Opsphere?" reference page. States the definition (an operational intelligence layer for DevOps, SRE and platform engineering teams that connects existing systems, supports evidence-backed operational investigations and maintains reusable Operational Context without replacing the systems that own the underlying data), the core capabilities (investigations, Operational Context with operational knowledge graph / investigation memory / similar incident matching, MCP Operational Gateway, trust posture), an explicit "what Opsphere is not" list (not an observability datastore, telemetry pipeline replacement, incident management system, generic MCP tool server or autonomous remediation platform), the audience, the system categories it works with, a model-agnostic AI-compatibility statement, and the data-ownership boundary. Includes an index of canonical platform URLs. - [Cursor Integration](https://opsphere.io/cursor-integration): Connects Cursor to Opsphere's operational intelligence layer through MCP — not a generic tool server. Cursor can call atomic Opsphere tools for direct operational queries (Kubernetes, AWS, Datadog, Vercel, DNS/TLS, GitHub) or invoke high-level Opsphere workflows that return structured, evidence-backed investigations with hypotheses, supporting and contradicting evidence, calculated confidence (HIGH/MEDIUM/LOW), an investigation timeline when source timestamps exist, and explicit verification conditions. High-level workflows can use reusable operational context while atomic tools stay focused on individual systems. Read-only by default, tenant and environment scoped; source systems remain authoritative for the underlying data. - [Codex Integration](https://opsphere.io/codex-integration): Gives OpenAI Codex (Codex CLI and ChatGPT desktop) access to Opsphere's operational intelligence layer through MCP — not just a tool catalog. Codex can call atomic Opsphere tools for direct queries (Kubernetes, AWS, Datadog, deployments, DNS/HTTP/TLS, repositories, CDN/edge) or invoke high-level Opsphere workflows that return a structured investigation: hypotheses, evidence, calculated confidence, timeline when real timestamps exist, verification conditions, observed facts, inferences and recommended next steps. High-level workflows can use shared Operational Context while atomic tools stay focused on individual systems — Opsphere does not automatically load context into every atomic call. Read-only by default; recommendations are structured, never autonomous changes. Source systems remain authoritative. Guided skills cover incident investigation, endpoint health, CI investigation and post-mortems. - [AI Engine Compatibility](https://opsphere.io/ai-engine-compatibility): Model-agnostic operational intelligence grounded in real evidence. Opsphere separates the operational intelligence layer from the AI model used to interact with it: the model helps interpret, reason and synthesise, while the tools generate evidence, Opsphere structures findings, Operational Context holds reusable knowledge, and the source systems stay authoritative. Model providers (OpenAI, Mistral, Anthropic / Claude) are kept distinct from AI clients / interfaces (Claude and Claude Code, Cursor, Codex, the Web Client, other MCP clients). Bring-your-own AI configuration is a supporting capability; managed AI is available depending on plan. No claims of universal model support or feature parity across every client. - [Web Client](https://opsphere.io/web-client): Opsphere's own visual interface to the operational intelligence layer, in the browser — not primarily a chat window. It shows the investigation, not just the answer: parallel hypotheses, operational evidence with visible sources, calculated confidence (HIGH/MEDIUM/LOW derived from evidence), an investigation timeline when real timestamps exist, explicit verification conditions, and relevant previous context. Operational Context is retrieved scoped to tenant, account and environment; Investigation Memory does not replace live queries. Cursor, Codex and Claude are other interfaces to the same layer. Read-only by default; no local IDE or MCP client setup required. - [Admin Panel](https://opsphere.io/admin-panel): Tenant configuration console for Cloud Catalog (clouds, environments, profiles), categorized tools and per-tool credentials, user invites, API keys for MCP clients, and usage plus activity logs. The control plane that prepares your connected stack before Cursor, Slackbot, or the web client ask questions. - [Pricing](https://opsphere.io/pricing): Simple, transparent pricing with Community, Professional, Team, and Enterprise plans. Start free with Community; scale with Team for operational intelligence and RBAC. Prices may display in local currency. Contact sales for Enterprise governance, SSO, and custom SLAs. - [About](https://opsphere.io/about): Company story, mission, and the team building Opsphere. We build operational intelligence tooling for infrastructure teams who need clarity without complexity. Platform-native, infrastructure-first — not another AI-hype experiment. - [Contact](https://opsphere.io/contact): Get in touch with the Opsphere team for demos, trials, pricing questions, and enterprise inquiries. Most teams are live within 4 minutes of starting setup. We respond within one business day. ## Integrations - [Integrations](https://opsphere.io/integrations): Browse the complete Opsphere integration catalog — 16+ connectors across cloud providers, CI/CD, monitoring, CDN, and project management. All integrations are read-only and require no agents or infrastructure changes. - [aws](https://opsphere.io/integrations/aws): Connect your entire AWS stack — EC2, ECS, Lambda, RDS, S3 and beyond. AI-driven incident detection, cross-service correlation, and root cause analysis without agents or infrastructure changes. Read-only IAM integration with sub-minute setup. - [terraform](https://opsphere.io/integrations/terraform): Detect infrastructure drift, correlate Terraform plan failures with runtime incidents, and surface IaC state context. Gain operational intelligence across Terraform-managed resources in Opsphere. Track apply errors, state lock incidents, and drift detection alerts alongside live production signals. - [kubernetes](https://opsphere.io/integrations/kubernetes): Correlate pod restarts, deployment rollouts, and namespace resource pressure with infrastructure signals. AI-native Kubernetes observability with cluster-level incident correlation in Opsphere. Monitor HPA scaling events, node pressure, and service mesh health alongside application incidents. - [vercel](https://opsphere.io/integrations/vercel): Link Vercel edge deployment events to backend incidents and infrastructure signals. Correlate frontend release timings with infrastructure behavior and reduce mean time to resolution. Track function invocation errors, edge cache misses, and build failures alongside backend health. - [railway](https://opsphere.io/integrations/railway): Operational intelligence integration for this tool. - [github](https://opsphere.io/integrations/github): Correlate GitHub Actions CI/CD failures, deployment merges, and pull request events with infrastructure incidents. Gain end-to-end operational visibility across development activity and production health. Track deployment frequency and correlate code changes with infrastructure stability. - [gitlab](https://opsphere.io/integrations/gitlab): Operational intelligence integration for this tool. - [bitbucket](https://opsphere.io/integrations/bitbucket): Link Bitbucket Pipelines to infrastructure incidents with full deployment-to-resolution traceability. Correlate pipeline failures and merge events with infrastructure signals in the Atlassian ecosystem. Works alongside Jira integration for end-to-end incident lifecycle tracking. - [datadog](https://opsphere.io/integrations/datadog): Surface Datadog metrics and alerts inside Opsphere without duplicating your observability stack. Correlate Datadog signals with infrastructure context for richer incident analysis and AI-assisted root cause. Preserve existing Datadog workflows while gaining cross-tool correlation. - [contentful](https://opsphere.io/integrations/contentful): Monitor Contentful delivery health and content release events alongside your infrastructure data. Correlate CMS publishing incidents with CDN and infrastructure signals in Opsphere. Track content API error rates and delivery SLA compliance. - [cloudflare](https://opsphere.io/integrations/cloudflare): Monitor Cloudflare edge health, Workers failures, DNS changes, and DDoS event correlation. Correlate Cloudflare signals with backend infrastructure for full-stack operational visibility. Track zone health, rate limiting events, and cache performance anomalies. - [akamai](https://opsphere.io/integrations/akamai): Detect Akamai CDN edge failures, delivery anomalies, and traffic spikes. Correlate content delivery incidents with origin infrastructure events in Opsphere. Gain visibility into cache purge operations and configuration change impact. - [azure](https://opsphere.io/integrations/azure): Correlate AKS cluster health, Azure DevOps pipeline events, App Service incidents, and resource health signals. Gain a unified operational view of your Azure environment in Opsphere. Monitor resource group health and service principal-level access events. - [jira](https://opsphere.io/integrations/jira): Auto-link infrastructure incidents to Jira tickets and track resolution velocity across teams. Reduce context switching between operational tooling and project management. Close the loop between ops alerts and engineering work items with automated ticket creation. - [argocd](https://opsphere.io/integrations/argocd): Track ArgoCD GitOps sync status, rollback events, and application health. Correlate GitOps deployment operations with infrastructure signals in Opsphere. Surface sync drift and failed application reconciliation alongside runtime incidents. - [sentry](https://opsphere.io/integrations/sentry): Correlate Sentry error spikes with infrastructure signals and deployment events. Accelerate root cause analysis with Opsphere's cross-layer incident context across application errors and infrastructure changes. Surface error rate increases alongside the infra events that caused them. - [pagerduty](https://opsphere.io/integrations/pagerduty): Operational intelligence integration for this tool. - [slack](https://opsphere.io/integrations/slack): Operational intelligence integration for this tool. - [prometheus](https://opsphere.io/integrations/prometheus): Operational intelligence integration for this tool. - [sonarqube](https://opsphere.io/integrations/sonarqube): Operational intelligence integration for this tool. - [algolia](https://opsphere.io/integrations/algolia): Operational intelligence integration for this tool. - [network-health](https://opsphere.io/integrations/network-health): Monitor Layer-3/4 network health, BGP events, and latency anomalies with cross-layer correlation. Correlate network incidents with application and infrastructure signals in Opsphere. Track packet loss, routing changes, and network path degradation alongside service health. - [custom-integrations](https://opsphere.io/integrations/custom-integrations): Build custom Opsphere connectors via REST API, webhooks, or the Opsphere SDK. Connect any internal tool, proprietary monitoring system, or data source to the operational intelligence layer. Supports event-driven and polling-based retrieval patterns. ## Use Cases - [small-sre-teams](https://opsphere.io/en/use-cases/small-sre-teams): How 2-person SRE teams use Opsphere for AI-driven observability and root cause analysis without enterprise tooling overhead. Get production-grade incident detection and correlation without staffing a dedicated observability team. Connect AWS, Kubernetes, and monitoring tools in minutes. - [aws-vercel-startups](https://opsphere.io/en/use-cases/aws-vercel-startups): Unify AWS and Vercel operations for startups — correlate incidents, reduce alert noise, and resolve faster. Gain a unified operational view of your cloud and edge infrastructure without enterprise tooling overhead. Ideal for teams managing both backend AWS workloads and Vercel-hosted frontend. - [ecommerce-microservices](https://opsphere.io/en/use-cases/ecommerce-microservices): Operational intelligence for distributed e-commerce — correlate services, trace root cause, and protect revenue-critical paths. Monitor checkout, inventory, and payment services alongside infrastructure health in Opsphere. Reduce mean time to resolution during high-traffic events and sale periods. - [terraform-native-teams](https://opsphere.io/en/use-cases/terraform-native-teams): Align Terraform-native infrastructure teams with live production context, AI correlation, and actionable runbooks. Surface IaC state alongside runtime signals to close the gap between infrastructure-as-code and operational reality. Reduce incident response time for teams managing large Terraform estates. - [reduce-tool-sprawl](https://opsphere.io/en/use-cases/reduce-tool-sprawl): Consolidate operational signals without losing visibility — Opsphere as the unified intelligence layer for your stack. Replace fragmented monitoring with a single operational context that connects alerts, infrastructure state, and AI correlation. Reduce the number of tools engineers must context-switch between. - [platform-engineering-teams](https://opsphere.io/en/use-cases/platform-engineering-teams): Operational intelligence for platform engineering teams — enable developer self-service, standardize environments, and maintain control. Surface infrastructure health signals in developer workflows and reduce toil on incident triage. Gain visibility across the full platform stack. - [ai-native-engineering-teams](https://opsphere.io/en/use-cases/ai-native-engineering-teams): Grounded operational context for AI-native engineering teams investigating live incidents. Use Opsphere to connect AI development tools with production infrastructure signals and root cause analysis. Operate codebases with AI-driven intelligence without losing operational accuracy. ## Comparisons - [AI SRE & Operational Intelligence Platforms](https://opsphere.io/en/compare/ai-sre-platforms): Neutral, educational category page. The market now groups several different products under "AI SRE": incident-management platforms with an AI SRE (example: Rootly), telemetry-native AI SRE built on a telemetry pipeline (example: Edge Delta), agent-driven production operations (example: Resolve AI), and a source-system operational intelligence layer (Opsphere). Includes ten platform-agnostic evaluation questions (data ownership, primary workflow, works outside incidents, root-cause method, context retention, what it can change, AI-client integration, whether it replaces an existing category, tenant/security scope, how value is measured) and a no-winner category matrix comparing primary public category, data/architecture starting point, investigation, persistent context and action model. No winner badges; each competitor cell is attributed and re-verified against official documentation. - [Opsphere vs Resolve AI](https://opsphere.io/en/compare/resolve-ai): Head-to-head comparison. Opsphere and Resolve AI overlap strongly in cross-system production investigation and persistent production context, but the default operating model differs: Opsphere is a read-only Operational Intelligence Layer that queries and correlates systems which remain authoritative for their data, while Resolve AI publicly positions agents as active participants in on-call and incidents with governed actions that can perform production changes under configured controls. Both support MCP; both maintain a queryable graph and learn from prior work. Attributed to Resolve AI's public product documentation and re-verified before each review. - [Opsphere vs Rootly](https://opsphere.io/en/compare/rootly): Head-to-head comparison. Rootly and Opsphere overlap substantially in evidence-backed investigation (parallel hypotheses, confidence scores, past-incident analysis, shown evidence), but their primary categories differ: Rootly is centered on the incident lifecycle — on-call scheduling, paging, coordination, status pages, retrospectives, plus an AI SRE — while Opsphere answers broad cross-stack operational questions with or without a declared incident and does not provide on-call or paging. Both offer an MCP server. Attributed to Rootly's public product documentation. - [Opsphere vs Edge Delta](https://opsphere.io/en/compare/edge-delta): Head-to-head comparison. Both accelerate production investigation but start from different data architectures: Edge Delta publicly describes a telemetry-native AI SRE with a telemetry pipeline as the layer under its AI teammates, while Opsphere keeps source systems (Datadog, Sentry and others) authoritative and queries them when evidence is needed, with no requirement to become a telemetry datastore. Overlap in investigation timeline, related issues, verification conditions and recommended actions; Edge Delta documents approved agent-executable actions, Opsphere is read-only by default. Attributed to Edge Delta's public product documentation. ## Locales English uses unsuffixed URLs. Spanish, French, and German append /es, /fr, or /de. Example: /platform/es, /integrations/aws/fr, /es (homepage).