EvoHub Docs Sign in
DeutschDE
Diese Seite liegt noch nicht auf Deutsch vor und wird auf Englisch angezeigt.

Uptime

Uptime monitoring

Mit KI verwenden
Als Markdown anzeigenDiese Seite als reiner Text, zum Einfügen in ein KI-Tool In Claude öffnenClaude Fragen zu dieser Seite stellen In ChatGPT öffnenChatGPT Fragen zu dieser Seite stellen
Mit Cursor / VS Code / Claude verbindenDiese Dokumentation aus Ihrem KI-Tool durchsuchen und lesen (MCP-Server)

URL des MCP-Servers

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

Claude Code

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

Claude (claude.ai und Claude Desktop): Einstellungen → Konnektoren → Benutzerdefinierten Konnektor hinzufügen und die URL oben einfügen.

Claude Desktop — claude_desktop_config.json

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

Cursor — ~/.cursor/mcp.json

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

VS Code — .vscode/mcp.json

{
  "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

Type Console label What it checks Target
HTTP HTTP Requests a URL and checks the response code, and optionally the response body, headers and SSL certificate. A full URL, such as https://example.com/health
Keyword Keyword Requests a URL and checks that the response body contains a word or phrase. A full URL
TCP TCP Opens a TCP connection to a port. host:port, such as db.example.com:5432
Ping ICMP (Ping) Sends a ping to a host. A host name or IP address
Heartbeat Heartbeat (cron / job) Waits for your job to ping EvoHub, and alerts when a ping is late. None. EvoHub gives you a URL to call.

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

Create a monitor

Open Uptime

In the EvoHub console, open Uptime and click New Monitor.

Name it and pick a type

Enter a Name and choose the Monitor Type. The fields below change to match the type.

Enter the target

Fill in URL, Host and port or Host, depending on the type.

Set the schedule

Choose a Check Interval and a Timeout.

Set the options you need

Open the sections below the form to add HTTP settings, SSL monitoring, assertions, performance and SLA settings, tags, and alerting. All of them are optional.

Create

Click Create Monitor. EvoHub opens the monitor's page and starts checking.

Check interval and timeout

Setting Options Default
Check Interval 15 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, 60 minutes 5 minutes
Timeout 10 seconds, 30 seconds, 60 seconds 30 seconds

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".

Assertion Operators Example
Status code is one of 200-299,301
Body contains, does not contain ok
JSON value equals, does not equal, contains, exists field $.status equals up
Header equals, contains field Content-Type contains application/json
  • 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

Status Meaning
Up The last check passed.
Degraded Checks pass, but slower than the slow threshold.
Down The last check failed.
Unknown The monitor has not been checked yet, or the last result was inconclusive.

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.

Zuletzt aktualisiert am