Exit1 Uptime Monitoring
dev.exit1Published by exit1.devOfficial publisherv0.4.0Updated Oct 24, 2026
Set up uptime monitoring from your editor: create checks, alerts, and query uptime. Can sign you up.
Overview
Exit1 uptime monitoring server that lets an assistant create website and API checks, configure alerts, and query uptime and response times.
- What you can do
- Read account plan, limits and usage, and list checks with their current status and SSL state, including public status page snapshots and individual check details and history. Query uptime percentages and response times over time ranges, and review past failures. Create, update, pause, resume or permanently delete monitors for websites, APIs, ping, TCP, DNS, domains and heartbeats. View alert settings, set email recipients and events, and connect Slack, Discord, Teams or generic webhooks. Fire a real test alert to confirm delivery, and follow a bundled setup playbook prompt.
- When to use it
- Useful when you want an assistant to set up monitoring for a project you just shipped by reading the repo for deployed URLs and health routes, then creating checks and alerts. Also suited to asking plain-language questions about uptime, downtime and response-time trends afterwards.
- Requirements
- Either the hosted remote endpoint with OAuth sign-in through a browser, or the local npm package run with npx on Node.js 18 or later. The local path uses an EXIT1_API_KEY from the dashboard, or starts in setup mode without one. An Exit1 account is needed; the hosted flow signs up inline, and setup mode can create a free account from an email address. Optional EXIT1_CREDENTIALS_PATH and EXIT1_API_URL variables exist.
Installation
In SourceWeft
- Open Exit1 Uptime Monitoring in the dashboard and add it to a workspace.
- Connect the required credentials. They are stored privately and never shown on public pages.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/dev.exit1%2Fexit1-mcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config. The client completes OAuth sign-in on first connect.
{
"mcpServers": {
"exit1-uptime-monitoring": {
"type": "http",
"url": "https://app.exit1.dev/mcp/v1"
}
}
}README
exit1-mcp
MCP server for Exit1 uptime monitoring. Let your AI assistant set up monitoring for the project you just shipped — read your repo, create the checks, configure alerts, and send a real test alert to prove it works — then ask it about uptime in plain language afterwards.
Two ways to connect
Hosted (recommended). No API key, no npm install, no plan requirement to get started. Run this in your terminal before starting a session: the login opens your browser, you sign in (or sign up) with Clerk, approve, and you're connected.
One line on purpose: pasting the two commands as separate lines is unreliable in some terminals (cmd.exe drops the second line). In old Windows PowerShell (5.1), where && doesn't parse, run the two halves one at a time. Connect before you start the session: MCP clients load servers at startup, so a server added mid-conversation isn't usable until a restart. On Claude Code versions without claude mcp login, start claude and authenticate via /mcp instead.
Local stdio. This npm package. Uses a Public API key from your dashboard. Use it when your client doesn't support remote MCP servers with OAuth.
Both expose the same tools. The hosted server is easier; the stdio one has no browser step, which some CI-ish setups prefer.
No account yet? Let the agent create one
Started without EXIT1_API_KEY, the stdio server doesn't exit. It starts in setup mode and offers one extra tool, create_account. Your agent calls it with your email address, and exit1 creates a free account and connects the server to it on the spot. Every other tool works straight away, and monitors start running.
Or from a terminal, before the session:
Either way exit1 emails you a link to claim the account. Alerts are only delivered once you claim it, so nobody can point exit1's alerts at an address they don't own. On the claim page you decide whether the agent keeps access. Unclaimed accounts are paused after 7 days and deleted after 30.
The tokens are saved to ~/.exit1/credentials.json and refreshed automatically, so later sessions connect without any setup. EXIT1_API_KEY, when set, always wins. Agents that don't use MCP can do the same with one HTTP call: see Agent signup.
Zero to monitored
Connect the server (above), then paste this into Claude Code, Cursor, Codex or any MCP-capable assistant, from inside your project:
Once connected, the server also ships a setup_monitoring prompt containing the full playbook — in Claude Code, /exit1:setup_monitoring.
Requirements
- Hosted: an Exit1 account. Sign-up happens inline during the OAuth flow.
- Local stdio: Node.js 18+, and either an API key from your dashboard (every plan can mint one, Free included) or no account at all: see No account yet?.
Supported clients
Remote MCP with OAuth is still rolling out across clients. Where it isn't supported yet, the stdio path below works everywhere.
Local stdio setup
Claude Code
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
Cursor
Add to .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally). Same shape as Claude Desktop above.
VS Code with Copilot
Run MCP: Add Server from the Command Palette, choose Command (stdio), enter npx -y exit1-mcp. VS Code uses a servers key rather than mcpServers:
Windsurf / Gemini CLI / Goose
Same mcpServers block as Claude Desktop, in mcp_config.json (Windsurf settings › MCP), ~/.gemini/settings.json, or via goose mcp add exit1 -- npx -y exit1-mcp. Restart the IDE or CLI afterwards.
Codex CLI
ChatGPT
Bridge the stdio server with mcp-remote, then add it under Settings › Connectors.
Tools
The hosted server requests checks:read, checks:write, alerts:read and alerts:write by default — not checks:delete, which has to be asked for explicitly. For the stdio path, tick the scopes you want when creating the API key.
Example prompts
- "Set up monitoring for this project."
- "Are any of my monitors down right now?"
- "What's the uptime for my API check over the last 30 days?"
- "Show me the last 10 failures for production."
- "Add a check on staging.example.com and send alerts to #ops in Slack."
- "Compare response times this week vs last week."
Configuration
Managing connections
Hosted connections are listed at app.exit1.dev/mcp and can be revoked there at any time. Revoking kills every token issued to that client immediately.
Development
npm test spawns the built server and asserts the surface a client actually sees: the tool
count, readOnlyHint / destructiveHint annotations, the setup_monitoring prompt, and that an
unknown tool returns isError rather than a protocol error. A second run starts it with no key
and no saved credentials and checks setup mode (create_account listed, other tools explain how
to get an account). It needs no API key and makes no network calls.
Why check:catalog exists
The tool catalog is deliberately duplicated between this package and the hosted OAuth server,
which lives in Mopra/exit1.dev at
functions/src/mcp-tools.ts. Two separate builds, no shared package, nothing at compile time
tying them together. npm run check:catalog fails if they drift on tool names or input schemas,
and warns on wording differences. CI runs it on every push and once a day.
Change a tool here, change it there — and run the check before releasing.
To run it against a local checkout instead of GitHub:
Releasing
Bump version in server.json to match, then re-publish the registry entry (see
below). The version string in src/index.ts is what clients see in
serverInfo — keep it in step with package.json.
MCP registry
server.json describes both distribution paths (the npm package and the hosted endpoint) for the
official MCP registry. The registry name is
dev.exit1/exit1-mcp, which requires proving control of exit1.dev:
npm ownership is proven by the mcpName field in package.json, which must stay equal to name
in server.json.
Quick Links
Also listed on the official MCP registry as dev.exit1/exit1-mcp.
License
MIT — see LICENSE.
The rest of exit1 is source-available rather than open source; this package is the exception, so it can be vendored and inspected freely by MCP clients.
Source: README.md at commit 082f0b3
Tools
0Version history
2- v0.4.0LatestOct 13, 2026
- v0.2.0Sep 16, 2026
Score
85% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
