Uptime monitoring

https://docs.evohub.io/mcp

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

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

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

{
  "servers": {
    "evohub-docs": {
      "type": "http",
      "url": "https://docs.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.

Credentials you enter are write-only. Once saved, a header's value and the Basic Auth password are never shown again, in the console or through the API: the field says Set — leave blank to keep. Leave it blank to keep the stored value, or type a new one to replace it. Credentials inside the monitor's URL, such as https://user:pass@… or a token, key, secret, password or api_key query parameter, are shown masked as ****; checks still use the URL as you entered it.

#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 URL, and the reason for the last failure
• days left on the SSL certificate, if monitored
• Longer history and SLA in EvoTrail, which opens EvoTrail's Uptime tab narrowed to this monitor: uptime over time, its SLA, response times and downtime (see EvoTrail)
• 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. A heartbeat monitor counts as one check each time it goes down or comes back, not per ping. See How billing works.

#Related

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