Opsis concepts

Opsis is the safety net for builders who ship fast. It works in two modes: launch checks before you ship, and live monitoring after. Before you ship, your coding agent proves your critical flows via the Opsis MCP server. After launch, Opsis watches your real users across whatever session and error tools you already run, finds the broken flows you'd never test for, proves each one with video and trace evidence, and hands you the exact fix to paste back into your editor.

Pre-deploy launch checks

Connect the Opsis MCP server to Claude Code, Cursor, or Windsurf. Your agent derives critical flows from the codebase, Opsis runs each one in a real Chromium browser on your machine, and the launch verdict lands on the project dashboard. Set up pre-deploy checks.

The same MCP server can also run an opt-in pre-deploy security scan: a confirmation-first OWASP Top 10 check that opens your app in a local browser and saves redacted findings to your dashboard.

Live monitoring: your real users

After launch, connect a source and Opsis turns real sessions into proven bugs. You're not locked into one vendor; bring whatever you already run, or use Opsis's own recorder. See Integrations for the full list (PostHog and Sentry via OAuth; Amplitude, Microsoft Clarity, Datadog via read-only keys; plus an optional first-party SDK).

Two proof engines

• Engine 1: signal detection & AI analysis. Opsis imports sessions and errors from your connected sources, runs deterministic signal detection (rage/dead clicks, console errors, network failures, checkout abandonment), then AI analyzes the suspicious ones.
• Engine 2: synthetic verification (Opsis MCP). For findings with high confidence or severity, Opsis runs a real browser to reproduce the bug. Video, screenshots, a trace archive, console logs, and network logs are stored as evidence.

Principles

• Findings must cite real sessions and signals; the AI is never allowed to fabricate evidence.
• Findings without sufficient evidence are automatically marked needs_more_data instead of being presented as fact.
• The suspected and verified statuses are strictly separated: verified means the MCP server reproduced the bug in a real browser.
• Live monitoring happens entirely in the dashboard. PostHog and Sentry connect with a single OAuth click; Datadog, Amplitude, and Clarity with a guided read-only key. The only code you ever add is optional (the Opsis SDK script tag for first-party recording, and the Opsis MCP server, which your coding agent runs locally for pre-deploy flow checks and an optional OWASP security scan).
• Opsis ships a real first-party SDK with two modes: initOpsis, a zero-dependency recorder that streams errors, failed requests and interactions straight to /api/ingest (no third party); and initOpsisWithPostHog, a thin wrapper for teams already on PostHog session replay. Don't want to add an SDK at all? Connect a tool you already run instead.

Workflow

Before you ship (optional): connect the Opsis MCP server to your coding agent and run launch checks. Every critical flow is proven in a real browser before your users hit it, with a launch-ready verdict on the dashboard.

1. Sign up for Opsis.
2. Connect a source (see Integrations): PostHog or Sentry in one OAuth click, a guided read-only key for Amplitude, Clarity, or Datadog, or the Opsis SDK script tag.
3. Opsis imports your recent sessions and errors and analyzes them: automatically on connect, and anytime after with Scan now.
4. Review findings in the dashboard, backed by proof & evidence: video, trace, screenshots, console and network logs.
5. Paste the fix prompt into Claude Code, Cursor, or Lovable, ship the fix, then re-run verification. A flow that now passes marks the finding fixed.