By Sarah Chen · Jul 7, 2026

How to Let Claude Code Manage Your Uptime Monitors (MCP Walkthrough)

I spend most of my working day in a terminal with Claude Code open. Deploys happen there. Debugging happens there. So when our uptime monitoring still required switching to a browser tab, it started to feel like the odd one out. This walkthrough is the setup I now run on every machine: Claude Code connected to UptyBots through MCP, so monitors are created, paused, and investigated without leaving the terminal.

I will also cover the part most tutorials skip: what exactly the AI gets access to, where your API key lives, and what I would tell a security reviewer. That is my day job, after all.

What You Need

Claude Code (the CLI) installed and working
Node.js 18+ on the same machine (node --version to check)
A UptyBots account and an API key

Step 1: Create the API Key

In the UptyBots dashboard, go to Account > API Keys and create a key. Two things worth doing properly:

Name it after the machine and purpose, like claude-code-workstation. When you rotate or revoke keys later, you will know exactly which one this is.
Copy it immediately. Keys start with upty_ and the full value is shown once. UptyBots stores only a SHA-256 hash of the key, so nobody (including support) can recover the plaintext later. If you lose it, you create a new one.

Step 2: Add the MCP Server to Claude Code

Edit ~/.claude/settings.json and add the server entry. Using npx means there is nothing to install or update manually:

{
  "mcpServers": {
    "uptybots": {
      "command": "npx",
      "args": ["uptybots-mcp-server"],
      "env": {
        "UPTYBOTS_API_URL": "https://uptybots.com",
        "UPTYBOTS_API_KEY": "upty_your_key_here"
      }
    }
  }
}

Restart Claude Code. It will start the MCP server as a local subprocess and discover its 15 tools automatically. To verify, just ask: "List my uptime monitors." If you get a monitor list back, you are done with setup. If you get an authentication error, the key in the config is wrong or truncated.

(Using Cursor, Windsurf, Zed, or another client instead? The MCP docs have the exact config file and format for each one. The server is identical.)

Step 3: The Workflows That Actually Matter

Here are the sessions I run most, straight from my terminal history.

Creating monitors as part of a deploy

> We just deployed the new customer portal.
  Create an HTTP monitor for https://portal.example.com
  with 1-minute checks, an SSL monitor for portal.example.com,
  and a port monitor for db.example.com port 5432.

Claude: Created 3 monitors:
  - "portal.example.com" (HTTP, 1-min checks) - active
  - "portal.example.com" (SSL) - active
  - "db.example.com:5432" (Port) - active

Three tool calls (create_http_monitor, create_ssl_monitor, create_port_monitor), no forms, no context switch.

Quiet deploys without false alerts

Alert noise during planned maintenance trains people to ignore alerts. Before a deploy window:

> Pause every monitor with "staging" in the name.

Claude lists the monitors, filters by name, and calls pause_monitor for each. After the deploy, "resume them and confirm they are up" brings everything back and verifies the first check passed. If you have ever forgotten to unpause a monitor for a week, you will appreciate that the resume and the verification happen in one step.

Incident investigation

This is where the conversational interface beats clicking around, because correlation across monitors is exactly what AI assistants are good at:

> The API felt slow this morning. Check incidents on the
  api-production monitor for the last 24 hours, pull its hourly
  stats, and tell me if the database port monitor saw anything
  in the same window.

Claude chains get_incidents, get_stats_hourly, and a second get_incidents on the port monitor, then summarizes: when the degradation started, how response times moved, and whether the database layer was implicated. What used to be four dashboard tabs is one question.

The weekly review

> Reliability report for the week: uptime percentage and
  incident count per monitor, worst performers first.

get_stats_daily across the account, aggregated and sorted. I paste the output into our team notes nearly verbatim.

The Security Review: What the AI Can and Cannot Do

Before rolling this out to a team, here is the honest assessment I would give in a review meeting.

The MCP server runs locally. Claude Code starts it as a subprocess and talks to it over stdio. There is no extra network service listening, and no third-party relay between you and the UptyBots API.
The API key is in a local config file. Treat ~/.claude/settings.json like any credentials file: correct file permissions, never committed to a repo, one key per person and per machine. Revoking a key in the dashboard kills exactly one setup.
Blast radius is your monitoring account, nothing else. The 15 tools cover monitors, stats, incidents, and notification history on your UptyBots account. The MCP server has no tools that touch your servers, DNS, code, or billing.
Destructive actions exist and you should know it. delete_monitor permanently deletes a monitor. Claude asks before destructive operations, but the operation is real. If a monitor was deleted by mistake, it needs to be recreated (the check history is gone).
Keys are stored hashed server-side. SHA-256, verified at authentication time. A database leak does not reveal usable keys.

My team policy: each engineer gets their own API key named after them, keys are rotated when someone leaves, and monitor deletion is done in the dashboard where you see exactly what you are clicking. Everything else (create, pause, resume, stats, incidents) flows through the assistant.

Troubleshooting the Two Failures You Will Actually Hit

"API error 401": the key is wrong, truncated, or was revoked. Check it starts with upty_ and matches what the dashboard shows as active.
Tools not appearing: you edited the config but did not restart Claude Code. MCP servers are discovered at startup.

Everything else (Node version, npx cache oddities, client-specific config paths) is covered in the troubleshooting section of the docs.

Where This Fits

The dashboard is still better for watching live charts during an incident and for auditing exactly what you are deleting. The terminal-plus-MCP setup is better for everything that is a sentence: create these monitors, pause those, what happened overnight, how did last week look. Since most of my monitoring interactions are sentences, most of my monitoring now happens in Claude Code.

If you want the wider picture of what the MCP server exposes and which clients it supports, start at the AI monitoring overview. If you want to see it from a non-developer's perspective, read the business owner's guide to MCP and Claude.

Frequently Asked Questions

Does this work with Claude Desktop too?

Yes. The same MCP server works with Claude Desktop, Cursor, Windsurf, Cline, Continue, Zed, VS Code with Copilot, JetBrains AI Assistant, and Amazon Q Developer. Only the config file location differs; see the docs.

Can Claude Code delete all my monitors if it misunderstands me?

Deletion goes through the delete_monitor tool one monitor at a time, and Claude confirms destructive intent before acting. If you want a hard guarantee, do deletions in the dashboard and use the assistant for everything else.

Do read operations cost anything?

Read operations (listing monitors, stats, incidents) work even when your account balance is empty. Write operations (create, pause, resume) require an active plan or credits.

Is the MCP server open source?

Yes, the source is on GitHub at uptybots/mcp-server, and the npm package is uptybots-mcp-server. You can read exactly what it sends before you run it.