Uptime monitoring

https://docs-dev.evohub.io/mcp

claude mcp add --transport http evohub-docs-docs https://docs-dev.evohub.io/mcp

{
  "mcpServers": {
    "evohub-docs-docs": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://docs-dev.evohub.io/mcp"
      ]
    }
  }
}

{
  "mcpServers": {
    "evohub-docs-docs": {
      "url": "https://docs-dev.evohub.io/mcp"
    }
  }
}

{
  "servers": {
    "evohub-docs-docs": {
      "type": "http",
      "url": "https://docs-dev.evohub.io/mcp"
    }
  }
}

EvoHub Uptime checks your services on a schedule and tells you when one stops answering, answers wrongly or slows down. This page covers the monitor types, how to create a monitor, and the settings that decide when a monitor counts as down.

#How it works

A monitor checks one target at a fixed interval. When a check fails, the monitor goes Down, EvoHub opens an uptime incident, and it alerts you through the monitor's notification channels and, if you choose, pages your team through On-Call. When a later check passes, the incident closes and EvoHub sends a recovery message.

Monitors live under Uptime in the EvoHub console. If you pick a team in the team switcher, the Monitors list shows that team's monitors, and new monitors belong to that team.

#Monitor types

Heartbeat monitors work the other way round from the rest. See Heartbeat monitors.

#Create a monitor

#Check interval and timeout

A check that gets no answer within the timeout fails. A monitor goes down on its first failed check, so you hear about an outage on the next check after it starts.

EvoHub does not currently let you choose the regions checks run from. Each check's location is shown in the monitor's Recent Checks table.

#HTTP and keyword options

Expected Status Code (HTTP monitors, default 200): the response code that counts as up.

Keyword (keyword monitors): the text the response body must contain. The match is case-sensitive.

HTTP Settings (HTTP monitors):

• Method: GET, POST, HEAD or PUT.
• Headers: request headers to send, for example an API token your health endpoint needs.
• Request Body: sent with POST and PUT.
• Basic Auth: a username and password.

#Assertions

HTTP monitors can check more than the status code. Open Assertions and click Add assertion. Every assertion must pass, or the check fails and the reason is recorded, for example "Expected status 200–299, got 503".

• A monitor can have up to 10 assertions.
• JSON paths look like $.status or $.items[0].id.
• Without a status code assertion, Expected Status Code still applies.
• Up to 1 MB of the response body is read.

#Slow responses and SLA

Open Performance & SLA on any monitor except a heartbeat:

• Slow if response takes longer than (milliseconds, 1 to 60000): a passing check slower than this marks the monitor Degraded instead of Up. Leave it empty to turn it off. Degraded counts as up for uptime and SLA.
• Also page on-call when slow: raises a lower-priority On-Call alert while the monitor is degraded, and resolves it when the monitor recovers. It needs a slow threshold and an escalation policy under Alerting.
• SLA target: an uptime percentage such as 99.9. When 30-day uptime falls below it, the monitor is marked as breaching its SLA.

#SSL certificate expiry

HTTP monitors can watch the site's certificate. Open SSL Monitoring, turn on Monitor SSL certificate, and pick an Alert threshold: 7, 14, 30 (the default) or 60 days.

When the certificate has fewer days left than the threshold, EvoHub sends a warning to the monitor's notification channels, for example "SSL certificate expires in 12 days (threshold: 30 days)". The warning is only sent while the monitor is up. The monitor's page shows the days left, and the Monitors list flags certificates with less than 30 days left.

#Tags

Use Tags to group monitors, for example by service or environment. Press Enter or a comma to add a tag. The Monitors list can be filtered by tag.

#Alerting

Under Alerting, pick an Escalation Policy to page your team through On-Call when the monitor goes down, and choose Re-alert while still down: every 5, 15 (the default), 30 or 60 minutes. See Uptime alerts and silence windows.

#The monitor page

Open a monitor from the list to see:

• its current status, and uptime for the last 24 hours, 7 days, 30 days and 90 days
• days left on the SSL certificate, if monitored
• a Response Time chart
• Recent Checks: status, location, latency, HTTP code, time and error of each check
• Incidents: when each outage started and ended, how long it lasted, and its cause
• Notification Channels linked to this monitor

From the header you can Pause and Resume checking, Edit the monitor, or delete it. A paused monitor runs no checks.

Individual check results are kept for 90 days.

#Monitor statuses

The list also marks monitors that are Paused, or muted by a silence window (Maintenance).

#Show a monitor on a status page

A status page component can follow a monitor, so your public page updates on its own when the monitor goes down. See Components and groups.

#Permissions and billing

Creating, editing, pausing and deleting monitors needs uptime:monitor:write. Owners, Admins and Members have it; Viewers can see monitors but not change them. See Roles and permissions.

Uptime checks are billed by usage. Heartbeat monitors are not metered. See How billing works.

#Related

• Heartbeat monitors
• Uptime alerts and silence windows
• Weekly email summary