# Agent instructions Source: https://docs.onepatch.dev/agent-instructions Give the agent your team's production context and rules for taking action. An organization admin can set workspace-wide instructions in **Settings → Agent**. Enter your instructions and click **Save**. They apply to new agent sessions; existing sessions keep the instructions they started with. Use short, specific statements about things the agent should know or do: ```text theme={null} Production runs in eu-west-1; us-east-1 is staging. Our checkout API is called “storefront” in customer-facing updates. Ask for approval before restarting the payments service. Include a rollback plan in pull requests that change database schemas. ``` Instructions guide the agent's behavior. Access is controlled by the permissions on your connected tools, such as your [AWS role](/connect-aws) and [network allowlist](/network-allowlist). For personal paging preferences, use **Settings → Paging → Paging rules**. See [Set up paging](/paging#tune-when-you-get-paged). ## Memory across chats The agent also keeps workspace-wide memory of what it learns, so later chats can build on earlier investigations. Use instructions for explicit team rules and conventions. If remembered context is wrong or outdated, tell the agent in chat. # Browser monitoring Source: https://docs.onepatch.dev/browser-monitoring See what a person did in your web app — pages, clicks, failed requests and JS errors, joined to your backend traces. `@onepatch/rum` records page views, clicks, `fetch` and XHR requests, JS errors and web vitals, and links each request to the backend trace it caused. Paste this into your coding agent, with the endpoint and token from **Workspace settings → integrations**: ```text theme={null} Add OnePatch browser monitoring to this frontend. First, install the setup skill (one-time): npx skills add 1patch/skills -s rum-instrument Then instrument the browser with the URL and write-only token. Endpoint: https://your-org.logger.onepatch.dev. Token: op_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. ``` The token is write-only, so it is safe to commit and ship in your bundle, like a Sentry DSN. Commit and push. Sessions arrive the next time someone loads your app. ## If your API is on another origin Same-origin requests need no setup. For an API on a different origin: 1. List that origin in `connectTracesTo`. 2. Add `traceparent` to that API's `Access-Control-Allow-Headers`. If the API accepts cookies, list `traceparent` by name — a `*` wildcard is not valid for requests that send credentials. ## By hand ```sh theme={null} bun add @onepatch/rum ``` ```ts theme={null} import { identifyUser, startRum } from "@onepatch/rum"; await startRum({ ingestUrl: "https://your-org.logger.onepatch.dev", ingestToken: "op_…", appName: "acme-web", // becomes service.name; pick one and keep it environment: "production", appVersion: commitSha, // required connectTracesTo: ["https://api.acme.com"], // cross-origin backends only // Required: the person, a resolver awaited once, or "anonymous". user: async () => (await getSession())?.user ?? null, }); // Later, when it changes — a sign-in, a workspace switch, a sign-out: identifyUser({ id: user.id, email: user.email, orgId: user.orgId }); ``` Call `startRum` once, on a path that only runs in the browser — it does not work during server-side rendering. `user` has no default, because telemetry with nobody attached cannot answer "what did *this* person do", which is most of why you want it. A resolver may return `null` — a login page, a load before the session request lands — and `(await startRum(…)).identified` tells you whether anyone was attached. Pass `user: "anonymous"` only for an app with no sign-in. On a sign-out or a workspace switch, pass `null` for what no longer applies: `identifyUser({ id: null, orgId: null })`. An absent key leaves the previous value on every later span. The [package README](https://github.com/1patch/rum) documents every option. ## Privacy The DOM is never captured, so keystrokes and form contents never leave the browser. Query strings are recorded. Set `scrubQueryStrings: true` if your URLs carry password-reset tokens or email addresses. # Changelog Source: https://docs.onepatch.dev/changelog What's new in OnePatch. The agent investigates incidents and pages the on-call responder when it needs a human decision or action, explaining what's needed and linking to the relevant fix or evidence. Your team's rules determine what warrants an interruption, and pages follow your on-call rotation through Slack DMs or SMS. See [Set up paging](/paging). The agent can follow your team's procedures across conversations. Save a procedure as a skill and run it from chat with a slash command. The agent shows why it reached a diagnosis and whether a fix is working, with production charts and traces alongside its findings. Admins can set workspace-wide instructions under Settings → Agent — your team's conventions, production context, and rules for taking action. The Services page brings together the agent's map of your system: each service's health, monitors, dashboards, and dependencies. See what calls what, including the external services your system relies on. Collect product analytics, crash logs, and other telemetry from native apps built with React Native and Expo. The agent investigates mobile issues alongside your backend telemetry. Claude Code, Codex, and Cursor can investigate production issues with your telemetry and hand work to the OnePatch agent from inside the editor. `onepatch onboard` connects your repository and coding agents to a OnePatch workspace; see [Coding agents](/connect-your-agent). Connect Linear from the Integrations page and the agent reads your issues for context while it investigates, and can create and update them in your workspace. It works under its own Linear identity, so everything it writes is attributed to OnePatch. ⌘K finds anything in the workspace — chats, incidents, monitors, and dashboards. The agent searches the same index, so a new incident starts with a look through past ones. The agent can use the internet while it investigates, scoped to a domain allowlist you control. See [Network allowlist](/network-allowlist). After a pull request merges, the agent watches the change in production and reports on the PR whether it held up. A review comment before merge says what it will watch, and a regression opens an incident. See [Verify PRs in prod](/verify-prs-in-prod). Point the agent at a Slack channel and it reads every new message there, opening a thread on the ones that need attention. Turn it on from the integrations screen or with `@onepatch watch` in the channel. See [Watched channels](/incidents-and-slack#watched-channels). When something breaks for a user, the agent can see what that user actually did — the pages, clicks, failed requests, and JS errors of their session, each joined to the backend trace it caused. Setup is adding `@onepatch/rum` to the frontend. See [Browser monitoring](/browser-monitoring). When a new incident turns out to be part of one already open, the agent merges them into a single episode. You follow one thread instead of a row of separate chats. Connect an IAM role from the Integrations page and the agent can describe resources, read logs, and take whatever actions the role's policies allow while it investigates. Permissions stay on your side, and every action lands in your CloudTrail named for the chat that made it. See [AWS](/connect-aws). One workspace-wide memory that carries across chats, so the agent doesn't start cold every time. Every workspace gets an ingest address. Forward alert email from any vendor and it becomes telemetry a monitor can act on. Scripts and unattended agents can query production telemetry and ask OnePatch to investigate issues using an API key scoped to your workspace. See [API keys](/mcp-server#api-keys). Chat, dashboards, monitors, the command palette, and onboarding are navigable by keyboard and announced to screen readers. Dashboards show how your services behaved during an incident, with filters and a shared time window across charts. Individual charts have links you can share with your team. Connect any OAuth-protected MCP server from the Integrations screen and the agent can use its tools. See [How OnePatch works](/how-onepatch-works#the-agent-over-your-data). DM the OnePatch bot, or @-mention it in a channel and it replies in a thread. Each conversation is a real chat that also shows up in the app, with the sender's name. See [Incidents and Slack](/incidents-and-slack). Fixes arrive as a PR against your connected repo rather than a suggestion in chat. # Connect your AWS account Source: https://docs.onepatch.dev/connect-aws Give the OnePatch agent access to your AWS account through an IAM role you control. The OnePatch agent can act in your AWS account while it investigates — describe resources, read logs, take whatever actions you permit. Access goes through an IAM role in your account: you decide what the role can do, and your CloudTrail records everything it does. ## Connect An org admin connects on the **Integrations** page under **AWS account**. The card shows two values: the **Principal** — the AWS identity your role will trust — and an **External ID** unique to your organization. In your AWS account, create an IAM role whose trust policy names that principal and external ID. **Copy trust policy JSON** on the card gives you the exact document: ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "" } } } ] } ``` Attach the permissions you want the agent to have. `ReadOnlyAccess` is a reasonable start. The agent can do exactly what the role's policies allow, and you can widen or narrow them at any time without touching OnePatch. Paste the role's ARN into the card and click **Connect**. OnePatch verifies by assuming the role from your workspace, and the card flips to **Connected** within a few seconds. If it stays on **Verifying…**, it shows the error from the last attempt — usually a trust policy that doesn't match yet. ## How access works Credentials are short-lived STS sessions, one hour at most, requested on demand while the agent works. Nothing long-lived is stored on either side. Every API call appears in your CloudTrail under a session named for the chat that made it, so you can trace any action back to the conversation. ## Disconnect **Disconnect** on the card stops OnePatch from requesting new credentials within about 30 seconds; sessions already issued expire within the hour. To revoke immediately, delete the role — or just its trust policy — in your account. # Connect Linear Source: https://docs.onepatch.dev/connect-linear Let the agent use Linear issues during investigations and create or update issues. Connect Linear and the agent can read issues for context, create issues, and update them as it investigates. The workspace connection acts as **OnePatch**, so its writes are attributed to the app. ## Connect On the **Integrations** page, find **Linear** and click **Connect**. A Linear workspace admin must approve the connection. The card shows the connected workspace when authorization completes. The connection is available across your OnePatch workspace, including investigations started by monitors. ## Use it Ask in chat or in an incident thread: ```text theme={null} Check Linear for known checkout timeout issues before investigating. ``` ```text theme={null} Create a Linear issue in the Payments team with this incident's findings and a link to the fix PR. ``` To remove the workspace connection, use **Disconnect** on the Linear card. # Connect your coding agent Source: https://docs.onepatch.dev/connect-your-agent Install the OnePatch plugin in Claude Code, Codex, or Cursor, or point any MCP client at the OnePatch MCP server. Connect a coding agent to your workspace and it can query your telemetry with SQL, read the OnePatch agent's incident investigations, and start or reply to workspace chats. Everything is scoped to your organization. The only writes are starting a chat and replying to one. Claude Code, Codex, and Cursor get a plugin. Everything else connects to the [MCP server](/mcp-server) directly. ## Install the plugin The `onepatch` CLI wires every coding agent on your machine in one step. ```sh theme={null} npm install -g onepatch onepatch install ``` Without Node, install the standalone binary instead: ```sh theme={null} curl -fsSL https://releases.onepatch.dev/install.sh | sh ``` `onepatch install` detects Claude Code, Codex, and Cursor and installs the OnePatch plugin in each. Pass an agent name to set up only one, as in `onepatch install cursor`. Each plugin can also be installed by hand. ```sh Claude Code theme={null} claude plugin marketplace add 1patch/claude-code-plugin claude plugin install onepatch@onepatch ``` ```sh Codex theme={null} codex plugin marketplace add 1patch/codex-plugin codex plugin install onepatch/onepatch ``` ```text Cursor theme={null} /add-plugin https://github.com/1patch/cursor-plugin ``` Codex also needs the MCP server in `~/.codex/config.toml`: ```toml theme={null} [mcp_servers.onepatch] url = "https://app.onepatch.dev/mcp" ``` The first call opens an OAuth sign-in with your OnePatch account. In Claude Code, run `/mcp` to sign in. In Codex, run `codex mcp login onepatch`. In Cursor, sign in under Settings, MCP. ## Other MCP clients Any MCP client that speaks streamable HTTP can connect without a plugin. ```json VS Code theme={null} { "servers": { "onepatch": { "type": "http", "url": "https://app.onepatch.dev/mcp" } } } ``` ```json Windsurf theme={null} { "mcpServers": { "onepatch": { "serverUrl": "https://app.onepatch.dev/mcp" } } } ``` ```text Any MCP client theme={null} Transport: HTTP (streamable) URL: https://app.onepatch.dev/mcp Auth: OAuth, sign in with your OnePatch account ``` Config files: `.vscode/mcp.json` (VS Code), `~/.codeium/windsurf/mcp_config.json` (Windsurf). Reload the window after editing. The first call opens an OAuth sign-in with your OnePatch account. For a script, CI job, or unattended agent that can't open a browser, use an API key. See [MCP server](/mcp-server#api-keys). # Monitor email alerts Source: https://docs.onepatch.dev/email-monitors Turn alert emails from another system into OnePatch investigations. OnePatch can monitor alerts from any system that sends email. The agent creates an address for each monitor; incoming messages become telemetry it can query alongside your traces, metrics, and logs. ## Set up Tell the agent which source to watch and what should count as an alarm: ```text theme={null} Create an unarmed email monitor for our CloudWatch checkout alarms. Give me an address to subscribe to the SNS topic. Treat ALARM messages as alerts, ignore subscription confirmations, and recognize OK messages as recovery. ``` The agent returns an address and creates the monitor. Add the address as a recipient in the source system, or forward its alerts there. If the source sends a subscription confirmation, ask the agent to check for it and help complete the subscription. Send a test alert, then ask: ```text theme={null} Did the test email arrive, and did the checkout monitor recognize it? ``` An **armed** monitor opens an incident when its condition fires. Ask the agent to arm it when you want automatic investigation, or leave it unarmed to record firings only. See [Monitors and dashboards](/monitors-and-dashboards#arming-a-monitor). ## Change or stop it Ask the agent to change which messages trigger the monitor, retrieve its address, or revoke the address. Mail sent to a revoked address is dropped. # Getting started Source: https://docs.onepatch.dev/getting-started From sign-up to your first dashboard. This guide covers setup end to end: creating your workspace, inviting your team, connecting GitHub and Slack, and sending telemetry. It takes a few minutes, plus a short wait while your workspace is provisioned. After setup, you work in chat. ## 1. Create your workspace Sign up at [app.onepatch.dev](https://app.onepatch.dev) and create an organization — name it and confirm your domain. This starts provisioning your **workspace**: a private OnePatch instance with its own agent. Provisioning usually takes a few minutes; the setup screen shows progress, and the onboarding chat tells you when the workspace is ready. Your telemetry, repositories, and the agent's work are private to your organization. ## 2. Invite your team Add teammates by email — anyone who may get paged, or anyone who wants to explore your telemetry. You can add members later under **Workspace settings → members**. ## 3. Connect GitHub The agent reads your repositories to understand your services, and opens pull requests when it has a fix. Click **Connect GitHub** and complete the OAuth flow. Install the OnePatch GitHub App on the account that owns the repositories you want to use. Select the repositories to make available to your workspace. You can change the selection later from the integrations screen. ## 4. Connect Slack Click **Connect Slack** and authorize the workspace your team watches. OnePatch creates an `#onepatch-alerts` channel where incident notifications land. ## 5. Send telemetry OnePatch reads OpenTelemetry. The onboarding chat hands you a block to paste into your coding agent — Claude Code, Cursor, or similar — which installs a setup skill and wires up the OpenTelemetry SDK. With your own endpoint and token filled in, it looks like this: ```text theme={null} Set up OnePatch OTel for this service. First, install the setup skill (one-time): npx skills add 1patch/skills -s otel-instrument Then set up OTel with the URL and write-only token. Endpoint: https://your-org.logger.onepatch.dev. Token: op_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. ``` The token is **write-only** — it can send telemetry but cannot read anything back — so it is safe to commit, like a Sentry DSN. The endpoint and token stay available on the integrations screen. OnePatch accepts standard OTLP over HTTP, both `http/protobuf` and `http/json`; the setup skill configures your exporter. The skill is open source at [github.com/1patch/skills](https://github.com/1patch/skills). Commit and push the changes. Telemetry starts the next time your app runs. That covers your services. To see what people actually do in your web app — pages, clicks, failed requests and JS errors, joined to the backend traces they caused — see [Browser monitoring](/browser-monitoring). ## 6. Your first dashboard When the first telemetry arrives, the agent reads the `TELEMETRY.md` file the setup skill wrote at your repository root — a short description of what your service emits — and drafts a first dashboard. It appears in the side pane next to the chat and refreshes as data lands. To change it, ask: ```text theme={null} Add a panel for p95 latency by route, and drop the host CPU chart. ``` ## Next * **Chats** — ask the agent to build dashboards and monitors, investigate your data, explore your code, or open a pull request. * **Dashboards** — the dashboards the agent has saved, updating live. * **Monitors** — every monitor, its schedule, and its current state. * **Workspace settings → integrations** — connected repositories, Slack, and your telemetry endpoint and token. For the model behind all of this, read [How OnePatch works](/how-onepatch-works). # How OnePatch works Source: https://docs.onepatch.dev/how-onepatch-works How OnePatch uses your telemetry and code to investigate problems and verify fixes. OnePatch is an AI SRE for your workspace. It reads your telemetry and code, builds monitors and dashboards, investigates problems, and proposes fixes. You can work with it in the app, in Slack, or through your coding agent. ## The agent over your data Send OpenTelemetry traces, metrics, and logs, and connect your GitHub repositories. The agent uses both to understand how your system works. [Getting started](/getting-started) covers setup. Connect [AWS](/connect-aws), [Linear](/connect-linear), or your own MCP servers from **Integrations** to give it more tools. Set [agent instructions](/agent-instructions) for team conventions and rules for taking action. The agent also carries learned context across chats through workspace-wide memory. ## Ask it to investigate or watch something Ask a question in chat, such as “Why did checkout latency rise after the last deploy?” The agent queries the data and reads the code to investigate. For ongoing visibility, ask it to build a [dashboard or monitor](/monitors-and-dashboards). Dashboards show live telemetry; monitors run scheduled checks. Monitors can also watch [email alerts](/email-monitors) from other systems. The [Services](/services) page brings together each service's health, monitors, dashboards, and dependencies. ## Follow an investigation An armed monitor that fires opens an incident. The agent investigates, records its findings with links to evidence, and works toward a resolution. It can tune a false alarm, open a fix PR, or ask for a decision or action it needs from you. Related incidents can be merged into one episode. A monitor recovering prompts the agent to reassess; it does not close the incident automatically. You can follow the report or reply in the incident's chat. See [Incidents and Slack](/incidents-and-slack). ## Verify what ships For runtime changes in connected repositories, the agent writes a verification plan on the pull request. After merge and deployment, it checks production against that plan and reports the result on the PR. A regression opens an incident. See [Verify PRs in prod](/verify-prs-in-prod) for deploy setup and coverage. ## Work from your existing tools [Slack](/incidents-and-slack#talking-to-the-agent-from-slack) supports direct messages, mentions, incident replies, and watched channels. [Coding-agent plugins](/connect-your-agent) let your editor query telemetry, read investigations, and hand work to OnePatch. These all use the same workspace context. # Incidents and Slack Source: https://docs.onepatch.dev/incidents-and-slack Follow investigations, inspect evidence, and work with the agent in Slack. What happens when a monitor fires depends on whether it is armed. ## Unarmed monitors When an unarmed monitor fires, OnePatch records the firing — its state, reason, and time — as telemetry you can query and chart. No one is paged and no incident is opened. ## Armed monitors When an armed monitor fires, OnePatch opens an **incident** and the agent triages it: 1. It investigates the firing against your live telemetry. 2. It tunes the monitor if the firing was a false alarm, proposes a fix for a real problem, or asks for an action or decision it needs from you. An incident is itself a chat: you can watch the investigation as it happens, step in, and review any pull request before it merges. Arming is opt-in per monitor; arm one only when a firing warrants an automated response. A firing episode opens a single incident, however many evaluations fire during it, with a cooldown after it resolves. ## Follow the investigation The incident report shows the current status, findings, and any action the agent needs from you. Open its evidence links to inspect the charts, tables, or traces behind a conclusion. Reply in the incident chat to add context or ask the agent to check something. When several incidents turn out to be the same problem, the agent merges them into one episode so you can follow one investigation. A monitor going healthy prompts the agent to reassess; it does not automatically close the incident. A merged fix still needs to deploy and be checked against telemetry. The report distinguishes a verified fix from recovery without a confirmed permanent fix. ## Slack High-severity incidents (P0 and P1) post to the `#onepatch-alerts` channel OnePatch creates in your connected Slack workspace. Lower-severity incidents remain in the app. The Slack card updates as the investigation progresses and links to the incident. The channel name, workspace, and connection are managed from the integrations screen. To receive a DM or text when an incident needs human help, [set up paging](/paging). ## Talking to the agent from Slack Every conversation is the same agent the in-app chat uses. Slack conversations appear in the app's sidebar with a Slack marker and the sender's name, so they stay visible to the rest of your team. Four ways to reach it: * **Direct message.** Message the OnePatch bot and it answers as the in-app chat does. The DM is one continuing conversation. * **@-mention in a channel.** Mention the bot in a channel it has been invited to and it replies in a thread. Each thread is its own conversation; reply in the thread to keep it going. * **Reply in an incident thread.** Under an incident card in `#onepatch-alerts`, a reply joins that incident's chat. No mention needed. * **Watched channels.** Point OnePatch at a channel — a bug-report or support channel, say — and it reads every new top-level message there without a mention, opening a thread on the ones that need attention. The bot only sees channels it has been invited to. `/invite @onepatch` in Slack first; removing it from a channel always stops it reading there. ## Watched channels Turn watching on from the integrations screen, or from inside the channel by mentioning the bot with one of these commands as the whole message: | Say | Effect | | ------------------------ | -------------------------------------------------------- | | `@onepatch watch` | Start watching this channel. It confirms in the channel. | | `@onepatch unwatch` | Stop watching. It still answers when mentioned. | | `@onepatch watch status` | Whether this channel is watched. | `watch this channel`, `start watching`, `stop watching`, and `are you watching` work as well. Anything longer is a message, not a command — `@onepatch watch out, the deploy is landing` is a question for the agent, and the channel's watch state stays as it was. What a watched channel does: * Every new top-level message from a person opens its own thread and chat. Replies in that thread continue the same conversation, so a report and its follow-up stay together. * A screenshot with a caption is a message; edits, deletions, and posts from other bots are not. * The agent stays quiet when a message doesn't need it. A channel that gets an answer to every "thanks!" is a channel people mute. * Only a member of your OnePatch organization can turn watching on or off — the sender's Slack email has to match a OnePatch account. Only public channels can be watched: everything the agent reads is visible to everyone in your organization, so a private channel is refused. So is `#onepatch-alerts`, where the agent would be triaging its own cards. * Up to 20 watched channels per organization. As a brake on a runaway channel, one channel opens at most 20 new chats an hour and all watched channels together at most 60; messages past that are dropped, and replies in threads already open are never counted. ## Firing history Every firing is recorded as telemetry, so you can chart it: ```text theme={null} Show me how often the error-rate monitor fired over the last week. ``` # OnePatch Source: https://docs.onepatch.dev/index An AI SRE platform that runs an agent on top of your telemetry. OnePatch is an AI SRE for your workspace. It uses your OpenTelemetry signals and connected repositories to investigate problems, build monitors and dashboards, and open pull requests with proposed fixes. Ask in the app, in Slack, or through your coding agent. ## Where to start Create a workspace, connect GitHub and Slack, send your first telemetry, and get your first dashboard. How the agent uses your telemetry and code to investigate problems and verify fixes. How the agent authors monitors and dashboards, and how they go live. What happens when a monitor fires, and where the alerts land. ## For your coding agent These docs are written to be read by an AI agent as well as a person. The full text is available as plain markdown at [docs.onepatch.dev/llms-full.txt](https://docs.onepatch.dev/llms-full.txt), and every page has a `.md` version at its own URL. Point your coding agent at either when you want it to answer questions about OnePatch. # MCP server Source: https://docs.onepatch.dev/mcp-server The OnePatch MCP endpoint, how to authenticate to it, and the tools it exposes. Your OnePatch workspace exposes an MCP server over streamable HTTP. Everything it returns is scoped to your organization. The only writes are starting a chat and replying to one. ```text theme={null} Transport: HTTP (streamable) URL: https://app.onepatch.dev/mcp Auth: OAuth, or a bearer token minted from an API key ``` To connect a coding agent or editor, see [Coding agents](/connect-your-agent). ## OAuth The first call from an MCP client opens an OAuth sign-in with your OnePatch account. ## API keys OAuth needs a browser. For a script, CI job, or unattended agent, use an API key: an org admin creates one on the **Integrations** page under **API keys**. You get a `client_id` / `client_secret` pair, and the secret is shown once. The pair doesn't expire; your code exchanges it for a 1-hour access token and sends that as the MCP bearer: ```sh theme={null} # 1. Exchange your key for a 1-hour access token TOKEN=$(curl -s -X POST https://auth.onepatch.dev/oauth2/token \ -d grant_type=client_credentials \ -d client_id=$ONEPATCH_CLIENT_ID \ --data-urlencode "client_secret=$ONEPATCH_CLIENT_SECRET" \ | jq -r .access_token) # 2. Call the MCP endpoint with it curl -s -X POST https://app.onepatch.dev/mcp \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' ``` Any MCP client that can send a static `Authorization` header works the same way. Each key is bound to one organization; its tokens can't read another customer's data. **Rotate** issues a new secret while the old one keeps working. Once the new secret is deployed, **Retire old secret** deletes the old one. **Revoke** deletes the key and every secret on it. ## Tools | Tool | What it does | | ------------------- | ------------------------------------------------------------------------------ | | `query_otel` | Read-only SQL over your telemetry (`otel.spans`, `otel.metrics`, `otel.logs`). | | `get_ingest_config` | The OTLP endpoint and token for sending telemetry. | | `list_incidents` | List incidents, filtered by status, severity, or who they wait on. | | `read_incident` | Read one incident's document and the investigation behind it. | | `list_chats` | List the chats in your workspace. | | `read_chat` | Read one chat's transcript. | | `start_chat` | Ask the OnePatch agent to investigate something. | | `send_chat_reply` | Post a reply into one of your chats. | # Monitors and dashboards Source: https://docs.onepatch.dev/monitors-and-dashboards What the agent builds, and how it goes live. Monitors and dashboards are the two artifacts the agent builds. You describe what you want in chat; the agent builds it. ## Dashboards A dashboard is a live view of your telemetry. You ask for one in plain language: ```text theme={null} Build a dashboard showing request rate, p95 latency by route, and error count over the last 24 hours. ``` The agent queries your telemetry to confirm the data exists, then builds the dashboard. It appears in the side pane next to the chat and refreshes on its own. Saved dashboards are listed on the **Dashboards** screen. To change one, ask — the agent edits it in place: ```text theme={null} Drop the CPU panel and add a table of the 20 slowest requests this hour. ``` ## Monitors A monitor watches your telemetry and reports one of three states: `healthy`, `firing`, or `unknown`. It is more than a threshold: in one check it can look across your traces, metrics, and logs, read your connected repository, and remember what it saw last time — enough to notice, for example, that errors climbed right after the latest deploy. You ask for one in plain language: ```text theme={null} Alert me if the error rate over the last 5 minutes goes above 10 per minute. ``` The **Monitors** screen lists every monitor with its schedule, current state, description, and — when firing — the reason. To change a monitor's threshold, schedule, or logic, ask the agent. The three states: * `healthy` — the condition being watched is fine. * `firing` — the condition tripped. A firing always carries a short, specific reason. * `unknown` — the check could not run (failed query, missing data). The screen also shows `pending` for a new monitor that has not checked yet, and `failed` for one that could not start — ask the agent to fix it. ## Going live A monitor is live as soon as the agent finishes writing it: it appears on the **Monitors** screen and starts checking. Edits take effect the same way. ## Arming a monitor An unarmed firing is only recorded. An **armed** monitor escalates: a firing opens an incident, and the agent investigates it against live telemetry. If the alert is a false alarm, the agent tunes the monitor; if it is real, it opens a pull request with a proposed fix. Your team reviews and approves what ships. You arm a monitor by asking: ```text theme={null} Arm the error-rate monitor. ``` [Incidents and Slack](/incidents-and-slack) covers what happens after a firing becomes an incident. # Network allowlist Source: https://docs.onepatch.dev/network-allowlist Limit which domains the OnePatch agent can reach. By default the agent can reach any domain. To restrict it, go to **Settings › Networking** and enter domains under **Agent internet access**, one per line. Each entry also covers its subdomains. Leave the field empty to allow everything. GitHub, the Anthropic API, and your OnePatch telemetry endpoint are always reachable. Changes apply within a few minutes. # Set up paging Source: https://docs.onepatch.dev/paging Turn on paging, choose an on-call schedule, and tune when the agent interrupts you. OnePatch's agent arms monitors, investigates incidents, and pages the on-call person when it needs human help. Pages arrive as Slack DMs or texts, separately from incident updates in your alerts channel. ## Turn it on 1. **Connect your team.** Invite responders under **Settings → Members** and connect Slack under **Settings → Integrations**. For DMs, each person's Slack email must match their OnePatch email. 2. **Verify your phone.** Each responder opens **Settings → Paging**, enters a number with its country code, selects the SMS consent checkbox, and clicks **Send verification code**. Enter the code and click **Verify number**. 3. **Choose channels.** Under **Notify me**, select **Slack me**, **Text me**, or both for each severity. Changes save automatically. Clearing all channels disables pages at that severity. 4. **Save a schedule.** An organization admin chooses who is on call under **On-call schedule** and clicks **Save schedule**. The options are below. 5. **Test delivery.** Each responder clicks **Send test page** and checks that their DM and text arrive. The test goes to the person clicking it; it checks delivery, independently of the schedule and paging rules. ## On-call schedules | Schedule | How it works | | -------------- | -------------------------------------------------------------------- | | **One person** | One responder until you change it. | | **By day** | Assign each weekday; the assignments repeat weekly. | | **Weekly** | Add responders in order; each takes one week, then the list repeats. | For **By day**, assign all seven days: blank days fall back to the first assigned person, starting from Monday. Day changes use the saving admin's browser timezone. **Weekly** handoffs currently happen Monday at 00:00 UTC. Saving a changed weekly list restarts the rotation from that week's Monday. For temporary coverage, edit the schedule and restore it afterward. **Remove schedule** stops new pages. ## Tune when you get paged Put shared production context and rules for requesting human help in **Settings → Agent**. These [agent instructions](/agent-instructions) apply to new sessions. Workspace admins set **Settings → Paging → Team paging rules**. These rules apply to everyone on call. Be specific about the environment, impact, and action needed: ```text theme={null} Do not page for staging-only failures. Text the on-call responder when production checkout is failing and recovery needs a human action. Use a Slack DM for decisions that can wait a few hours. Routine fix reviews can wait until working hours once service has recovered. ``` Click **Save rules**. The rules guide subsequent page decisions within each responder's selected channels; they cannot enable a channel that person turned off. Click **Not urgent** on an unwanted paging DM to dismiss that page. To change future paging, an admin can follow **Add team rule**, review the suggested rule, and save it for the workspace. ## When a page arrives Click **Acknowledge** in the Slack DM or reply `ack` to the text. Then open the incident to see what needs doing. An unanswered SMS gets an **URGENT** follow-up after five minutes, to the same person. Acknowledgment stops that follow-up; it does not resolve the incident. OnePatch does not automatically pass an unanswered page to the next responder. # Services Source: https://docs.onepatch.dev/services Find a service's health, monitors, dashboards, and dependencies in one place. The **Services** page shows the agent's map of your system. Each service links to its monitors and dashboards, and the dependency graph shows what calls it and what it depends on, including external services. ## Read service health Health comes from the service's monitors: a firing monitor makes the service firing, and a check that cannot determine its state makes health unknown unless another monitor is firing. A service without evaluated, active monitors is unmonitored. A healthy status describes the checks attached to that service; it does not mean every possible failure is covered. Open a monitor to inspect what it watches. ## Update the map The agent maintains the map from your repositories and telemetry. Ask it to correct missing services, dependencies, or monitor assignments: ```text theme={null} The checkout API depends on Stripe. Add that dependency and show which monitors cover checkout. ``` ```text theme={null} Add the queue-lag monitor and the worker dashboard to the payments worker. ``` # Verify PRs in prod Source: https://docs.onepatch.dev/verify-prs-in-prod How each pull request is verified against production after it deploys. The agent verifies every merged pull request against production. It writes checks from the diff while the change is still in review, runs them after each deploy, and reports on the pull request. It is on for every connected repository; the only setup is the [deploy signal](#what-it-needs). ## The plan When a pull request opens, the agent reads the diff and writes two kinds of checks: the effect the change promises and what the touched code could break. A latency fix that does not drop latency counts as a regression too. Each signal is measured before the merge, so every check compares against a real baseline; a check with too little traffic to judge never counts against the change. The plan is one review comment: ```text theme={null} Batches Redis writes on checkout so p95 drops. Watching - [ ] checkout p95 latency below the pre-merge baseline - [ ] checkout 5xx rate holds - [ ] order-confirmation queue lag holds Would fail it - p95 not below baseline by the 24h checkpoint - 5xx above 2× baseline at any checkpoint - queue lag over 60s at any checkpoint `changes/acme--api--pr-42` · armed — awaiting merge ``` The agent edits this one review in place, and never approves, requests changes, or blocks a merge. If the change evolves before it merges, ask the agent to revise the plan. Changes that cannot alter runtime behavior (docs, lockfiles, formatting, CI config, tests) are skipped without a comment. ## After the merge Verification starts at the first successful deploy into each of your environments, in the order you deploy them. The clock starts at the deploy, not the merge. Checks run continuously for the first 10 minutes, then once at 1 hour, 24 hours, and 72 hours. For a risky change, like a data migration or a payment path, the agent watches longer and says so in the plan. The review's last line is the status: `armed — awaiting merge`, then `armed — awaiting deploy`, then `soaking` with a checkpoint count. It ends one of four ways: * `verified` — every check held through the last checkpoint. * `regression` — a check tripped; the line names it and links the incident. * `inconclusive` — no deploy observed within 30 days. * `retired` — the pull request closed without merging. The status names the environment once your deploy signal labels one. ## When a check trips A regression opens an incident, like any armed monitor firing (see [Incidents and Slack](/incidents-and-slack)). The agent first looks for another explanation, like a parallel deploy or an upstream outage; if that clears the pull request, it resolves the incident and records the explanation. Otherwise the agent proposes a revert or a fix. Merging it is up to you. ## When every check holds The agent ticks the checkboxes, sets the status to `verified`, and deletes the temporary monitor. No incident, no Slack message, no row left on the Monitors screen. ## Where it shows up Besides the review: pull requests the agent opened carry a verification footer on **Home**, the **Monitors** screen shows a `changes/…` row per pull request in flight, and the Deploys dashboard shows a verdict per version and environment for the last 30 days. ## What it needs A connected repository covers every pull request opened after connecting, drafts included. The one thing OnePatch has to work out is the deploy signal: which of your CI/CD events means "this shipped". The agent settles it from your GitHub workflow runs, deployment statuses, and commit statuses. Plans written before then say so; ask the agent to re-arm them. If no GitHub event reflects your deploys, ask the agent to set the signal by hand. If your deploys happen where GitHub cannot see them, the agent may open a pull request adding one line to your deploy step: a `curl` that reports "deployed" to the telemetry endpoint your apps already use. Decline it and the agent uses the best signal it can see. ## Limits and turning it off Up to 20 changes verify at once; a pull request past the limit waits for capacity, and is skipped after three days. To stop verifying a repository, or all of them, ask the agent. Stopping applies to new pull requests; changes in flight finish. Once one repository is excluded, coverage becomes an explicit list, and repositories you connect later must be added to it.