# Uptime.com MCP > Uptime.com MCP Server monitors your website and APIs from over 30 global locations. It lets you check service status, pull performance stats, or get a root cause analysis of an outage—all through conversation with your AI agent. ## Overview - **Category:** developer-tools - **Price:** Free - **Tags:** uptime-monitoring, site-reliability, api-monitoring, incident-alerts, root-cause-analysis, network-diagnostics ## Description You connect this server to your AI client so you can stop clicking through dashboards and start asking questions about your service status. It handles the whole shebang—checking if your site's up, figuring out why it went down, or checking who needs to get an alert when things go sideways. **Setting Up Your Checks.** You can start by seeing what’s running right now using `list_checks`, which shows every single monitor check you’ve got active. If you need a new check, you use `create_check`; this lets you set up monitors using HTTP protocols for web requests, API checks for backend services, or ICMP packets for basic network connectivity. When you're done setting it up, you can get granular details on any specific monitor by running `get_check`, and if you need to adjust something—like changing a URL or tightening the monitoring interval—you run `update_check`. If a check is dead weight, you use `delete_check` to pull it from your active list. **Tracking Service Status and History.** To see if everything’s running smooth, you can list all of your monitors using `list_checks`, or quickly get the current details on one with `get_check`. For a deep dive into performance, you use `get_check_stats`; this pulls historical uptime statistics and detailed performance metrics for any single monitor check. If you need to know if something went down recently, you grab a chronological log of recent service transitions using `list_recent_alerts`, which shows every UP/DOWN status change. **Diagnosing Outages.** When an alert triggers, you don't just want to know it failed; you want to know *why*. You run the `get_root_cause_analysis` tool. This spits out a detailed report explaining the probable cause of any recent service failure or critical alert. **Managing Scope and Notifications.** To understand your entire system, you can pull basic account details with `get_account_info`. When it comes to knowing who gets paged when things break, you use `list_contact_groups` to see all the defined recipients and notification groups. You also check which outside systems are hooked up by listing integrations using `list_integrations`, so you know if Slack or PagerDuty is handling the message flow. If you wanna know how widely your service is being checked, you use `list_monitoring_nodes`; this gives you a list of all global nodes Uptime.com uses for testing coverage across different regions. **Running Diagnostics.** You can also run `get_check_stats` to pull historical data on any specific monitor check, while `get_root_cause_analysis` provides the detailed breakdown of why an alert triggered in the first place. ## Tools ### create_check Sets up a new monitor check for your service using HTTP, API, or ICMP protocols. ### delete_check Removes an existing monitor check from your active monitoring list. ### get_account_info Retrieves basic information about your Uptime.com account profile. ### get_check Fetches specific details for a single, existing monitor check. ### get_root_cause_analysis Generates a detailed report explaining the probable cause of a recent service alert or failure. ### get_check_stats Retrieves historical uptime statistics and performance data for any given check. ### list_recent_alerts Retrieves a chronological list of the most recent service uptime alerts (UP/DOWN status). ### list_checks Lists every monitor check currently active in your account. ### list_contact_groups Displays all defined contact groups and notification recipients for alerts. ### list_integrations Lists which third-party systems (like Slack or PagerDuty) are connected to your account. ### list_monitoring_nodes Shows a list of all global nodes used for testing and monitoring coverage. ### update_check Modifies an existing monitor check, such as changing its URL or monitoring interval. ## Prompt Examples **Prompt:** ``` List all active monitor checks in my account. ``` **Response:** ``` I've retrieved your checks. You have 5 monitors active including 'Main Website' (UP), 'API Gateway' (UP), and 'Staging Server' (DOWN). Which one would you like more details on? ``` **Prompt:** ``` Show me the recent alerts history. ``` **Response:** ``` I've fetched the alert history. There were 2 downtime events today: 'Staging Server' (Down for 15m) and 'API Gateway' (Down for 2m). Both are currently back online. Shall I retrieve the RCA for the Staging Server outage? ``` **Prompt:** ``` What is the uptime percentage for the 'Main Website' check? ``` **Response:** ``` Retrieving statistics... The 'Main Website' (ID: 10293) has an uptime of 99.98% over the last 30 days, with an average response time of 150ms. No significant failures detected recently. ``` ## Capabilities ### Check service status You can list all active monitor checks, or create a new check for HTTP, API, or ICMP protocols. ### Retrieve outage history The agent fetches a log of recent UP/DOWN transitions and critical service alerts. ### Diagnose failure causes You run the `get_root_cause_analysis` tool to get detailed reports explaining why an alert triggered. ### Get performance data The agent queries uptime statistics and historical performance metrics for any specific monitor check. ### Manage notifications You list contact groups or integrations to understand the notification flow when an outage occurs. ### Review global coverage The agent lists all monitoring nodes, letting you see exactly where your services are being checked globally. ## Use Cases ### The API Gateway is flaky. A backend developer noticed the main API was having intermittent failures. They ask their agent to run `get_root_cause_analysis` on the 'API Gateway' check. The agent returns a report showing the failure consistently spikes during high load, pointing them straight to a database bottleneck they didn't know about. ### Need to audit all endpoints. A Web Administrator is onboarding new services and needs to make sure everything is monitored. They use `list_checks` to see what’s active, then run `create_check` repeatedly for every new endpoint, ensuring zero gaps in coverage. ### After a major outage. The SRE team needs to report the incident timeline. They ask their agent to pull data using `list_recent_alerts`. The agent provides a clear log of the exact time the service dropped and when it recovered, which is crucial for post-mortem reports. ### Updating an old URL. A Web Administrator changes the staging server's endpoint. Instead of manually updating every monitoring tool, they simply use `update_check` via their AI agent to point all existing monitors to the new location in one go. ## Benefits - Get immediate visibility into failures by running `list_recent_alerts` to see a full history of downtime events, keeping you ahead of minor issues before they become major incidents. - Skip the guesswork on failure diagnosis. Using `get_root_cause_analysis` provides technical reports explaining *why* something broke, saving hours of manual investigation time. - Keep your monitoring setup accurate with `list_checks` and `create_check`. You can manage all endpoint definitions and protocols (HTTP, API, ICMP) right from the chat interface. - Measure performance over time. Running `get_check_stats` gives you concrete uptime percentages and average response times for reports—no more guessing about reliability. - Streamline team communication by checking out your notification setup using `list_integrations` and `list_contact_groups`. You know exactly who gets paged when a service goes down. ## How It Works The bottom line is: it lets you run a full-scale service audit and incident review without leaving your AI workspace. 1. Subscribe to the Uptime.com MCP Server and provide your API Token. 2. Your AI client runs commands against the global monitoring infrastructure using the available tools. 3. You receive structured, plain-language reports directly in chat—showing status, stats, or RCA. ## Frequently Asked Questions **How do I check my site's uptime percentage using get_check_stats?** You pass the specific monitor ID to `get_check_stats`. The tool returns historical data, including calculated uptime percentages and average response times over the chosen period. **What is the purpose of list_monitoring_nodes in Uptime.com MCP Server?** `list_monitoring_nodes` shows you all the global physical locations where your services are being tested. This lets you understand exactly how widespread your monitoring coverage really is. **Can I create a new monitor check using create_check?** Yes, `create_check` allows you to set up entirely new monitors for HTTP, API, or ICMP protocols. You just need to provide the necessary endpoint details. **How do I find out who gets notified during an outage?** Run `list_contact_groups` and `list_integrations`. This shows you all the defined contact groups and third-party services (like Slack or PagerDuty) that receive alerts. **Should I use get_root_cause_analysis or list_recent_alerts?** `list_recent_alerts` gives you a chronological history of the UP/DOWN status. `get_root_cause_analysis` takes an alert and tells you *why* it happened, giving deeper context. **What does running `list_checks` show me about all my active services?** It gives you a quick inventory of every monitor check set up in your account. This function provides the name, type (HTTP, API, etc.), and current status (UP/DOWN) for all monitors without fetching detailed performance metrics. **How do I use `update_check` if a service's endpoint changes?** You use `update_check` to modify the parameters of an existing monitor, like changing the target URL or adjusting the check interval. This lets you maintain continuous monitoring coverage without having to delete and recreate the entire rule. **If I run `delete_check`, what happens to the historical data for that monitor?** Running `delete_check` removes the active monitoring rule from your account. However, it does not purge any past performance metrics or alert history associated with that specific check ID. **Can I see the reason why my website went down via AI?** Yes! Use the `get_root_cause_analysis` tool and provide the Alert ID (PK). Your agent will retrieve the detailed RCA report explaining the failure. **How do I create a new HTTP check to monitor a URL?** Use the `create_check` action. Provide the name, address (URL), and set the `check_type` to 'HTTP'. The agent will instantly register the new monitor. **Is it possible to see the performance statistics for a monitor?** Absolutely. Run the `get_check_stats` query with your Check ID to retrieve performance and uptime metrics for that specific service.