upbutler.com

Create a workspace + API key with no human in the loop For autonomous agents.

Plug in a service: monitor + status page component in one call The fastest path: creates a monitor for the URL (or a heartbeat when you pass periodSec), creates the status page if needed (statusPage = slug or name), and adds a component that follows the monitor.

Send a heartbeat (no API key needed — the token is the secret) Call at least every periodSec.

Push one component status by its push token (no API key needed) (No API key required.)

Identify the calling key

Get a fresh claim link for this unclaimed workspace, and optionally email it to your human Only for agent-bootstrapped workspaces nobody has claimed yet.

List monitors All monitors in the workspace with their current state and last check.

Create a monitor Create an uptime monitor.

Get a monitor with recent checks and stats

Update a monitor Partial update; any create field may be sent.

Delete a monitor and its history

Run a check right now Runs the monitor immediately and returns the full result with evidence.

List checks (raw results, 30 days)

Get one check with full evidence

MCP monitor: tool schema baseline and change history For kind "mcp".

MCP monitor: accept the pending schema change Makes the tool list the server serves now the new baseline, which ends the degraded/down state a breaking schema change caused.

Balance monitor: history and run-out projection For kind "balance".

Per-check metrics (time to first token, MCP step timings, balance) Numbers recorded on every check of an mcp, llm or balance monitor, with p50/p95 per metric.

List status pages

Create a status page Theme presets: midnight, grid, daylight, paper.

Get a status page with components

Update page settings, theme, branding or domain

Delete a status page, its components and subscribers

Check the custom domain DNS now Verified when the domain CNAMEs to the target shown in pages.get dns.value (or resolves to the same IPs).

Get the rendered public status data (as visitors see it)

Replace the ordered list of component groups

List subscribers of a status page

Status page analytics: views, visitors, agent reads, subscribers Who looks at a status page, when, and whether agents read it.

Per-incident analytics: views, peak, time to first view, notifications For each public incident of the page: reads while it was open and reads of its page afterwards (people, agents, bots), the busiest five minutes, seconds from the start to the first view / first agent read / first delivered subscriber notification, notifications sent and failed by subscriber type, and unsubscribes within 48 hours of them.

Remove a subscriber

Add a component to a status page A component is a row on the status page.

Update a component (name, group, source, visibility)

Delete a component

Manually set (or clear) a component status Overrides win over automatic status until cleared with status=null.

Push statuses for many components at once Body: {"statuses": {"<component key>": "operational" | {"status": "major_outage", "message": "..."}}}.

List incidents and maintenance

Get an incident with its timeline and AI reports

Report an incident Declare an incident (agents: use this when you detect a problem yourself).

Post an incident update Adds a timeline update, optionally changing status and component impact.

Change an incident's impact or title, or publish a draft automatic incident Automatic incidents get their impact from how much of the page is affected (one component of many in a major outage is "major", not "critical").

Resolve an incident Without a message, UpButler writes the resolution note (AI recovery summary when available).

Generate (or regenerate) the AI report for an incident

Schedule maintenance Components show "Under maintenance" during the window; it starts and completes automatically.

List alert channels

Create an alert channel Where your team (or your agent) gets alerted.

Update an alert channel

Delete an alert channel

Send a test notification

Public status of a page (no auth) Overall status, components with uptime, active incidents and maintenance.

Public incident history of a page (No API key required.)

One public incident with its updates (No API key required.)

Subscribe to a status page (email, webhook, Slack, Discord or Telegram) Agents: subscribe with {"type":"webhook","url":"https://your-agent/hook"} to receive signed incident.*, maintenance.* and component.status_changed events and automate downtime handling.

View a subscription (requires its manage token) (No API key required.)

Change which components a subscription follows (requires the manage token) (No API key required.)

Unsubscribe (requires the manage token) (No API key required.)

Public response-time series of a component (p50/p95) Only for components the page owner published (page settings.showResponseTimes + component showResponseTimes, monitor-backed).

Current workspace, plan, limits and usage Useful first call for agents: shows what the key can do and how much quota is left.

Every metered plan limit: used, limit, percent and warning threshold One row per metered limit of the plan (monitors, status pages, components and email subscribers on the fullest page, members, API keys, emails, AI reports, agent runs and preview runs this month, fix attempts in the last 24 hours, …).

Rename the workspace

List workspace members and pending invites

List API keys

Create an API key The secret is returned once.

Revoke an API key

Poll the event stream Every state change in the workspace (monitor.down/up/degraded, incident.*, maintenance.*, component.status_changed …), newest first.

Available plans and limits (No API key required.)

Start a checkout to upgrade the workspace Returns a Polar checkout URL.

Dry run: what an import would create Reads your UptimeRobot, Better Stack or Statuspage.io account and returns every item with action create | exists (already imported) | skip (with reason), plus plan-limit warnings.

Run an import (background job) Starts the import and returns the job right away; poll import.status.

Progress and result of an import job

Recent import jobs

Acknowledge an incident or a down monitor Take ownership: stops "still down" reminders and escalation, records an internal timeline entry and emits incident.acknowledged to the channels that were alerted.

Remove an acknowledgement Reminders and escalation resume where they stopped.

Who is on call right now For every schedule (or one with scheduleId): the person on call now, until when, and whether it is an override.

List on-call schedules

Get a schedule with upcoming shifts

Create a weekly on-call rotation (Business plan)

Update a schedule

Delete a schedule

Put someone on call for a period (override) Overrides win over the rotation; the most recently created one wins when they overlap.

Remove an override

Members with their paging contact status

List escalation policies

Create an escalation policy (Business plan) Ordered levels: level 1 is paged as soon as an incident opens; each next level after `afterMinutes` if nobody acknowledged.

Update an escalation policy

Delete an escalation policy

Audit log: sign-ins, 2FA changes, keys, members, billing, deletions, domains Newest first, kept 400 days.

List check regions and probe health Regions monitors can be checked from (use the ids in a monitor's "regions").

Per-region latency and failures for a monitor

List private probes Probes you run inside your own network ("private locations"), with status (online / offline / never_connected), last seen, version and checks run.

Create a private probe Registers a probe and returns its token ONCE, with the docker command that starts it.

Rename a private probe

Rotate a private probe token Issues a new token (returned once) and revokes the old one at once: the running probe gets 401 until it is restarted with the new token, and its monitors report "no data" meanwhile.

Delete a private probe Revokes the token and removes the probe.

Proxy monitor: the pool and the latest result per proxy Each proxy of the pool (scheme, host, port, credential hint; never the URL) with its latest result from every region or private probe: outcome, failure class, successful samples, exit IPs and country, connect / tunnel / first-byte / total time.

Record a deploy Mark a release so incidents can be correlated with it (AI reports, charts, incident timelines).

List deploys Newest first.

Delete a deploy marker

List deploy hooks, with the last delivery and the last guard verdict Deploy hooks are the URLs a hosting provider (Vercel, Railway, Netlify, Cloudflare, GitHub, or any script) posts deploys to; each production deploy becomes a deploy marker and starts a deploy guard automatically.

Create a deploy hook URL Returns `url` (https://upbutler.com/hooks/deploy/<token>) to paste into the hosting provider's webhook settings.

Recent deploy hook deliveries What arrived on the deploy hooks, newest first: accepted (marker + guard), preview (a preview deploy whose checks were queued; previewRunId names the run), ignored (still building, failed build, duplicate, a preview that could not be checked) or rejected (bad signature, unreadable body), with the reason.

Get a deploy hook

Update a deploy hook Rename it, change the guard window, include previews, pin it to one service, or set a signing secret per provider (vercel, railway, netlify, cloudflare, github, coolify, generic; null removes one).

Rotate a deploy hook URL Issues a new token and retires the old URL immediately.

Delete a deploy hook

List project → monitor mappings Which monitors a deploy of each project is guarded against.

Preview which monitors a deploy would be guarded against Dry run of the mapping for a project name and/or the URL it is served from.

Set the monitors a project's deploys are guarded against Replaces the mapping for one project / service name (as the provider sends it; case-insensitive).

Remove a project mapping

List deploy guards Newest first, with their verdicts.

Get the preview check settings Whether preview deploys are checked, with which monitors, which preview hosts are trusted, whether stored request headers go to previews, and whether a GitHub commit status is posted.

Change the preview check settings Only the fields sent are changed.

List preview check runs Newest first.

Check a preview deployment now Runs the project's HTTP monitors once against the given preview URL (origin swapped, path, query and assertions kept) and returns the verdict: state pass, fail or error, with each check diffed against its latest production result.

Is my pull request's preview green?

Ask the Fix with Claude responder to repair a failing preview For a run whose state is fail: pages the Fix with Claude responder with the failing checks and their production diff, and asks it to push ONE fix commit to that pull request's own head branch (never the default branch, never a fork, never a new pull request).

Weekly digest settings Workspace timezone, who receives the Monday 08:00 email, when the next one goes out and the last runs.

Change the workspace timezone or your weekly digest opt-in subscribed applies to the signed-in member (owners are subscribed by default).

Build the weekly digest on demand Returns the digest JSON (same shape as the digest.weekly event) and, with format=html, the rendered email.

Draft a postmortem with AI Writes a blameless markdown postmortem (summary, impact, timeline from updates, checks and deploy markers, root-cause hypotheses, contributing factors, what went well/poorly, action items) plus a customer-safe summary, and stores it as a new version.

Get an incident's postmortem Current markdown, the public summary, publish state and the version list (history=true includes every version's markdown).

Save an edited postmortem (new version) Send baseVersion (the version you edited) to get a 409 instead of overwriting someone else's changes.

Publish a post-incident report to status pages Posts body (default: the postmortem's public summary) as a public update on the resolved incident and notifies subscribers.

List incident templates Reusable title/status/impact/message presets.

Create an incident template

Update an incident template

Delete an incident template

Fill in a template Returns title, message, status, impact and components ready for POST /incidents or POST /incidents/{id}/updates.

List agent responders AI agents that can be on call.

Get an agent responder With a responder key, use id "me" to read your own settings and guardrails.

Create an agent responder Registers an AI agent that can be paged.

Update an agent responder delivery.headers replaces all headers (send the masked value back to keep one).

Delete an agent responder Its incident tokens stop working immediately.

Send a test page Sends a test page (type "responder.test", example packet, no token) through the same delivery path as a real page.

Wait for the next page of an agent responder (long-poll) For agents without a public endpoint: be an on-call responder by waiting for pages in a loop (wait → handle → wait).

Confirm that a page was received Stops the page from being delivered again.

List runbooks

Get the runbook of a monitor, a component or the workspace

Write a runbook Markdown instructions for whoever responds: what to check, how to restart, when to roll back, when to give up and escalate.

Delete a runbook

Incident handoff packet: everything a responder needs One compact document: the incident, affected monitors with per-region failing evidence and the last good check, components, recent deploys with timing (suspect = shipped within 30 minutes before), related past incidents and how they were resolved, the AI analysis, the timeline, runbooks, your guardrails and links.

Claim an incident (take ownership under a lease) The first claimant owns the incident; anyone else gets 409 with who holds it.

Renew your claim (heartbeat) Extends the lease.

Add an internal timeline note Log what you found or did.

Post a public update as a responder For agent responders: follows the responder's public-update mode.

Approve (and optionally edit) an agent's draft public update Publishes the draft to the status page, attributed to the agent and marked as approved by you.

Reject an agent's draft public update

Verify the fix: re-check the incident's monitors from every region now Runs fresh checks of every monitor in the incident from all of its regions (waits up to about a minute for remote regions) and returns pass/fail per monitor and region.

Hand the incident back to humans For when you cannot fix it (or should not try).

Briefly mute the incident's monitors Silence the monitors of this incident (or some of them) while you work, e.g.

Take an incident over from an agent Ends the agent's claim and incident token and acknowledges the incident in your name.

Mute a monitor for N minutes Checks keep running and components keep following the monitor, but no incident is opened and nobody is alerted until the mute ends (people: up to 24 hours; agents: up to 60 minutes).

End a mute now

Watch monitors after a deploy and get a regression / clear verdict Agent deploy flow: ship → guard → verdict → roll back.

Get a deploy guard and its verdict status: watching | regression | clear | cancelled.

Stop a deploy guard

Ask the coding agent to fix an incident (Fix with Claude) Pages the workspace's Fix with Claude responder for this incident with the evidence (what changed, suspect deploys, repro command) and an incident-only token.

Report the pull request that fixes an incident For the fixing agent (incident token) or a person: stores the pull request on the incident and shows it on the timeline.

What changed: last good vs first bad check, suspect deploys, repro command The evidence section of the handoff packet on its own, plus the state of the fix.

Fix with Claude: responders, linked repositories and attempt limits

Set the workspace limits for Fix with Claude The spend guard for your own Claude usage: at most this many fix attempts are started per 24 hours across the workspace (default 5).

Link a project to its GitHub repository Tells UpButler which repository is behind a project, so evidence links to commits and diffs and the fixing agent knows where to open the pull request.

Remove a repository link

Preview the files and commands of a Fix with Claude delivery Returns what the customer adds on their side without creating anything: github_actions = the workflow file `.github/workflows/upbutler-fix.yml`; local = the listener command; routine = the instructions to paste into a Claude Code routine.

Turn on Fix with Claude: create the responder and get the files to add One call per delivery.

Change the fix policy of a responder enabled: false turns the responder back into an ordinary agent responder (pages carry no fix instructions).

Test Fix with Claude end to end with a synthetic incident Creates a private synthetic incident ("nothing is down"), pages the responder for it through the real delivery path with a real incident token, and waits for the other side to answer with a note (action "fix-test").

Start an agent run (no API key needed with the monitor's ar_ token) Tell UpButler an agent started working.

Report progress of a run and read the kill switch Call it at every step (or at least every few minutes).

Read the kill switch of a run without reporting progress For polling between steps or from a watchdog thread.

End a run: success, failed or cancelled Always end a run, also when it failed or was told to stop (status "cancelled").

List the runs of an agent monitor, with a fleet summary

Get a run with its timeline Totals, budget use, active detections, the kill switch state and the last 500 timeline events (progress, detections, stop actions).

Kill switch: tell a running agent to stop, pause or slow down The agent reads it in its next progress response ({continue:false, action, reason}); a stop webhook, if the monitor has one, is sent right away.

Lift a stop, pause or slow-down that the agent has not acted on yet The next progress response says continue:true again.

Kill switch for a whole fleet: stop every running (or every flagged) run of a monitor

The agent runs behind an incident: task, last steps, spend, kill switch state For incidents on agent monitors.

Stop the agent runs behind an incident Sets the kill switch on runs of this incident's agent monitors: the given runIds, or every flagged run when omitted.

Apply an upbutler.yaml: create and update monitors, heartbeats and status pages to match the file Declarative setup.

Export the workspace as an upbutler.yaml For workspaces set up by hand: returns the monitors, heartbeats, status pages and components as a declarative file (`config` as JSON, `yaml` as text).

List hosting accounts connected for rollbacks, and the alert action settings A connected hosting account (Vercel, Netlify) is what lets "Roll back" in an alert put the previous production deployment back.

Test a connected hosting account Calls the provider with the saved token, refreshes the project list and reports whether the token still works.

Map project names to provider projects Only needed for deploys that do not come through the provider's own deploy hook (those carry the provider project id already), or when the name on your deploy markers differs from the provider's project name.

Choose which actions alerts carry Turn Roll back, Let Claude fix and Mute 1h on or off for every alert of the workspace, and decide whether a rollback needs a signed-in member (default: the signed link is enough in email, Slack, Discord and Telegram; links delivered through webhook channels always need a sign-in).

What can be done about an incident, in plain words Returns the incident as one plain sentence (`summaryPlain`: what users see, since when, the deploy it followed), the suspect deploy, and what is possible: roll back (state `ready`, `connect`, `map` or `none`; pass preview=true to ask the provider which deployment would be restored), let Claude fix, mute.

Roll production back to the deployment before the incident's suspect deploy Asks the hosting provider (Vercel instant rollback, Netlify restore deploy) to serve the previous production deployment again.

Error rate of an error-rate monitor: the current window, per minute, and the failing paths Counts come from the request logs the hosting provider drains to the monitor.

Problem reports end users sent for a status page, with the signals they added up to Reports are what users typed: untrusted text, for the team only.

Mark one report as new, known or noise noise = not a problem: it stops counting toward signals and its reporter gets no "fixed" email.

Delete one report, or everything an email address sent to this page (erasure requests)

Mark a report signal (and all its reports) as known or noise noise closes the signal, resolves the internal "checks are green" incident if it opened one, and no reporter is emailed.

AI summary of what users report (one signal, or the last 24 hours for a component) Uses one AI report from the monthly quota.

Spend per source and day, with baselines and anomalies Everything the Spend page shows: each spend source (Agent Runs, balance monitors in USD, connected provider accounts) with its daily spend, month to date, what is usual for it and the days that were unusual; the agent runs spending the most today; the spend monitors with their caps and budgets.

List connected provider accounts

Connect a provider account as a spend source Polls the provider's cost API every 15 minutes with an admin / management key: OpenAI (admin key, GET /v1/organization/costs), Anthropic (Admin API key, GET /v1/organizations/cost_report), OpenRouter (management key, /activity and /credits), Vercel (access token + team, GET /v1/billing/charges).

Rename a spend source, replace its key or pause polling

Disconnect a provider account Removes the stored key and the spend history of this source, and takes it out of every spend monitor.

Read a provider account now Polls the cost report right away instead of waiting for the next 15-minute poll.

What UpButler did: deploys guarded, regressions caught, incidents agents handled The value section of the weekly digest on its own: deploys shipped and how many were guarded, regressions caught after a deploy and how fast, incidents agent responders took, fixes by pull request, rollbacks, agent runs stopped, monitors added, spend watched.

What a lower plan would pause, slow and hide Counts what moving this workspace to a plan would change, with the rules that are applied when a trial ends or a subscription is cancelled: monitors paused and slowed, components hidden, custom domains removed, agent responders switched off, spend monitors paused.

Is a third-party service down?

The upstream catalog with current status (no auth) Every service in the catalog with its current status and verdict, one line each.

Upstream dependencies of this workspace The third-party services this workspace declared it depends on, each with its current upstream status, plus the paging policy for incidents that are likely upstream.

Declare (or change) a dependency on an upstream service Say that this workspace depends on a catalog service.

Remove a dependency

Set how likely-upstream incidents are paged inform (default): the team is alerted, agent responders are told it is upstream and not to change code, a Fix with Claude responder is not started.

Suggest dependencies from env var names and package names Pass the NAMES of environment variables (never values) and/or package names from package.json / requirements.txt; returns the catalog services they point at and whether each is already declared.

List drill scenarios and how drills are scored What each scenario simulates, what ends it and what a good responder does.

Start an incident drill Opens a synthetic, internal-only incident on the given monitors and lets the responder chain run for real: the escalation policy pages its agent responders with a packet marked `drill: true` that shows a simulated failure.

List drills, newest first

Get a drill and, once it ended, its report While the drill runs: status and timing only (the cause stays hidden).

End a running drill now Cancels the drill: the synthetic incident, its tokens and queued pages are removed and no score is recorded.

List drill schedules

Schedule a recurring drill Runs a drill weekly, monthly (the first chosen weekday of the month) or quarterly at the given hour in the workspace timezone.

Change a drill schedule

Delete a drill schedule

List signed uptime attestations of a status page Newest first.

Issue a signed uptime attestation now Measures the page over the period and signs the result with UpButler's Ed25519 key.

Get a signed uptime attestation

Public keys that sign uptime attestations (no auth) Every Ed25519 key that ever signed an attestation, retired ones included, as raw base64url and as JWK.

Fetch a signed uptime attestation by id (no auth) Returns the signed document { payload, signature } and the result of checking it against the published keys.

Live verified uptime of a public status page (no auth) Uptime of the last 30 or 90 UTC days measured by UpButler's own probes, per component, with self-reported components listed separately (verified: false).

GitHub App installations connected to this workspace Whether the UpButler GitHub App is available, and the installations connected to this workspace with their repositories and settings.

The incident room: merged timeline, roles, tasks, approvals, who is here One read of everything about working an incident together.

Assign incident commander, comms or ops To a workspace member (user id) or an agent responder (agr_…).

Tick or untick a task Agents: tick a task when you have done what it says (task ids are in GET /incidents/:id/room).

Ask a human to approve something before you do it For agent responders: say what you want to do and wait.

State of an approval request (long-poll with wait)

Catch me up: what happened, what was tried, the hypothesis, open tasks A summary for someone joining late, written from the room's timeline with the status page's AI rules.

Ask a question about this incident Answered from the incident's own context (timeline, evidence, runbooks, tasks) with citations to timeline entries (`citations[].id`).

Access settings of a status page (internal pages) Who may view an internal page (allowed email domains, invited addresses, workspace members), its shared links (names and hints, never the tokens), allowed networks, which internal sections it shows, and the viewers signed in right now.

Change who may view an internal page and what it shows Only the given fields change.

Create a shared access link / page access token A long random token, read-only: open `url` on a wallboard or TV (the token moves into a cookie and leaves the address bar), or send it as `Authorization: Bearer <token>` to the page's machine endpoints (status.json, status.agent.json, /mcp).

Rotate a shared access link (the old token stops working at once)

Delete a shared access link

Create or rotate the signing secret for signed embeds Signed embeds put an internal page's live widget inside another site (your customer's dashboard) without a sign-in.

Turn signed embeds off (tokens signed with the old secret stop working)

Sign viewers out of an internal page One session (`id` from GET /pages/:pageId/access), every session of an address (`email`), or everyone (`all: true`).