Downdetector MCP Server Status and Outages

Overview

The Downdetector MCP Server provides a lightweight, self-hosted bridge between Downdetector outage data and the Model Context Protocol (MCP). It continuously gathers availability reports across platforms and regions, normalizes them, and exposes the results through an MCP-style API so downstream systems (including LLM agents, monitoring dashboards, and alerting pipelines) can consume up-to-date outage context.

This server is useful when you need programmatic, real-time visibility into service interruptions that users report on Downdetector, and want that information delivered in a structured, model-friendly form. Typical uses include enriching agent prompts with current outage context, powering incident-triggered notifications, or feeding time-series dashboards for post-incident analysis.

Features

• Real-time collection of Downdetector outage data (scraping or API-driven, depending on source)
• MCP-compatible endpoints for easy integration with model pipelines
• Filtering by platform, region, and severity
• Delta and historical views: current incidents plus recent trends
• Configurable polling interval and cache TTL
• Webhook and streaming support (SSE/WebSocket) for push-style updates
• Docker-ready for quick deployment and environment isolation
• Metrics and health endpoints for observability (Prometheus-compatible labels if enabled)

Installation / Configuration

Clone the repository and run locally or in Docker. Below are typical steps — adjust to the runtime indicated in the repository (Node, Python, etc.).

Install from Git:

git clone https://github.com/domdomegg/downdetector-mcp.git
cd downdetector-mcp

Local (example using Node.js):

# install dependencies
npm install

# copy example env and edit as needed
cp .env.example .env

# start the server in development
npm run dev

Docker:

# build
docker build -t downdetector-mcp .

# run (example)
docker run -d \
  -p 8080:8080 \
  -e PORT=8080 \
  -e POLL_INTERVAL=60 \
  -e REGIONS="us,eu" \
  --name downdetector-mcp \
  downdetector-mcp:latest

Common environment variables

Example .env:

PORT=8080
POLL_INTERVAL=30
REGIONS=us,eu,ap
PLATFORMS=twitter,instagram,facebook
CACHE_TTL=20
LOG_LEVEL=info

Available Tools / Resources

Typical endpoints and resources (names and paths may vary slightly by release):

• GET /mcp/status
  • Returns current aggregated outage state for requested platforms/regions.
• GET /mcp/incidents
  • List of active incidents, with timestamps, severity, and report counts.
• GET /mcp/history?platform=twitter&period=24h
  • Recent trend data for a given platform and time window.
• GET /health
  • Basic liveness and readiness checks.
• GET /metrics
  • Optional Prometheus-style metrics if enabled.
• POST /webhooks/register
  • Register a webhook to receive incident updates.

Example curl (query current status):

curl "http://localhost:8080/mcp/status?platform=twitter&region=us"

Example SSE subscription (stream real-time updates):

curl -N "http://localhost:8080/mcp/stream?platform=instagram"

Response example (JSON snippet):

{
  "platform": "twitter",
  "region": "us",
  "status": "degraded",
  "reports": 1274,
  "updated_at": "2026-04-10T12:34:56Z",
  "incidents": [
    {
      "id": "inc_20260410_1",
      "severity": "major",
      "reports": 1200,
      "first_seen": "2026-04-10T11:50:00Z"
    }
  ]
}

Use Cases

• Enrich LLM prompts with live outage context
  • Example: A conversational assistant that answers “Is Twitter down?” can call /mcp/status and include the returned summary before generating a response.
• Trigger incident notifications in Ops pipelines
  • Example: Configure a webhook to post to a Slack channel or run automation when reports cross a threshold.
• Feed observability dashboards
  • Example: Pull /mcp/history into Grafana to visualize report volume spikes over the past 24 hours.
• Geo-aware troubleshooting and routing
  • Example: Route support requests to regional teams when a region-specific outage is detected.

Notes and Best Practices

• Respect Downdetector’s terms of service and scraping guidelines — use provided APIs if available and avoid overly aggressive polling.
• Tune POLL_INTERVAL and CACHE_TTL to balance freshness against rate limits and resource usage.
• Use webhooks or streaming for real-time integrations to reduce polling overhead.
• Add proper observability (logging, metrics) and configure alert thresholds to avoid alert storms.

If you need quick examples or integration snippets for a specific runtime (Node/Express, Python/FastAPI, or Docker Compose), see the