Check Types

SysTeam HealthChecks supports 11 check types for comprehensive service monitoring. Each type is optimized for a specific protocol or use case.

HTTP/HTTPS (Uptime Check)

Monitor websites and REST APIs with HTTP/HTTPS checks. Supports custom methods, headers, request body, and content matching.

Features

• HTTP Methods: GET, POST, PUT, DELETE, PATCH, HEAD
• Custom Headers: Add API keys, authorization tokens
• Request Body: JSON, form data, or raw text
• Content Matching: Verify response contains expected text
• SSL Monitoring: Certificate expiry alerts (30/14/3 days)
• Authentication: Basic Auth, Bearer Token, Form Login
• Follow Redirects: Toggle redirect following on/off

Content Matching

Verify the response contains or matches specific content:

SSL Certificate Monitoring

HTTPS checks automatically monitor SSL certificates. You receive alerts when:

• Certificate expires within 30 days (warning)
• Certificate expires within 14 days (urgent)
• Certificate expires within 3 days (critical)
• Certificate has expired

Form-Based Authentication

For checks that require logging in through a web form before checking a protected page, enable HTTP Form Login. Configure:

• Login URL — The form submission endpoint
• Login body — Form fields (e.g., username and password)
• The system will first authenticate, then check your target URL with the session cookie

API Scenario (Multi-Step)

Test complex API workflows with multi-step scenarios. Chain requests together — extract tokens, pass variables between steps, and validate responses with JSONPath assertions. Perfect for testing authentication flows, CRUD operations, and API integrations.

Features

• Multi-step execution: Chain multiple HTTP requests in sequence. Each step can use data extracted from previous steps.
• Variable extraction: Extract values from JSON responses using JSONPath (e.g., $.auth.access_token) and use them in subsequent steps via {{variable_name}} syntax.
• JSONPath assertions: Validate response body structure and values. Assert that specific fields exist, match expected values, or meet numeric thresholds.
• Response time assertions: Ensure each step or the entire scenario completes within acceptable time limits.
• Header assertions: Validate response headers (Content-Type, Cache-Control, etc.).
• Fail-fast: Scenario stops on the first failed step — no wasted requests after a failure is detected.
• Shared variables: Define reusable variables (base_url, credentials) once and reference them across all steps.

Assertion Operators

JSONPath Assertions on HTTP Checks

You can also add JSONPath assertions to regular HTTP/Uptime checks (not just API Scenarios). In the Edit Check modal, add assertions in the Response Assertions section. If any assertion fails, the check is marked as DOWN even if the HTTP status code is 200.

OIDC / Identity Provider Health Check

Monitor SSO and identity provider infrastructure — Keycloak, Okta, Auth0, Azure AD, or any OIDC-compliant provider. Supports multi-realm monitoring: configure multiple realms/tenants in a single check and get per-realm status aggregation (like geo monitoring for identity).

Features

• OpenID Discovery: Automatically checks /.well-known/openid-configuration per realm — verifies issuer, endpoints, and JWKS availability.
• Multi-realm bulk monitoring: Monitor 10, 50, or 100+ realms in a single check. Each realm gets individual UP/DOWN status. Overall status aggregates: all UP → UP, some DOWN → DEGRADED, all DOWN → DOWN.
• Token endpoint health: Validates the token endpoint responds correctly (without actual authentication).
• JWKS certificate expiry: Monitors signing key expiration dates and alerts before they expire (like SSL certificate monitoring for identity).
• Multi-tenant URL patterns: Supports dynamic paths like https://sso.example.com/{tenant_id}/auth/realms/{realm}/ — common in Keycloak multi-tenant deployments.
• Auto-detect provider: Automatically identifies Keycloak, Okta, Auth0, or generic OIDC from the discovery response.

Alert Examples

• Single realm down: "🟡 Keycloak DEGRADED — 1/10 realms down: PMI Production"
• Multiple realms: "🔴 Keycloak DOWN — 8/10 realms unreachable. Possible infrastructure issue."
• JWKS expiry: "⚠️ Keycloak ALG: signing key expires in 7 days"

ICMP (Ping Check)

Test server availability using ICMP ping. Measures round-trip time and packet loss.

Metrics

• Average round-trip time (RTT)
• Minimum / Maximum RTT
• Packet loss percentage
• Packets sent / received

TCP Port Check

Verify TCP port availability. Useful for checking databases, mail servers, and custom TCP services.

TCP checks report: connection success/failure, response time, and optional banner (the first bytes sent by the server after connection).

UDP Port Check

Check UDP services like DNS, NTP, and SNMP. Includes special handling for NTP servers.

DNS Check

Monitor DNS records with advanced features including multi-record monitoring, SOA tracking, and hijacking detection.

Record Types

• A — IPv4 address
• AAAA — IPv6 address
• MX — Mail exchanger
• TXT — Text records (SPF, DKIM, DMARC)
• CNAME — Canonical name
• NS — Name servers
• SOA — Start of Authority

Advanced DNS Features

• Multi-record Monitoring — Check multiple record types at once (A, MX, NS in a single check)
• SOA Serial Tracking — Alert on zone changes by monitoring the SOA serial number
• DNS Hijacking Detection — Validate that DNS resolves to expected IP addresses. Alerts when unexpected IPs are detected.
• SPF/DKIM/DMARC Validation — Email security monitoring for your domain
• Domain WHOIS Expiry — Alerts before your domain registration expires
• Multi-server iteration — The agent queries all configured DNS servers (not just the first), with 1 retry on timeout

FTP/SFTP Check

Monitor FTP, FTPS, and SFTP server availability with authentication support.

Database Check

Monitor database connectivity for PostgreSQL, MySQL, MongoDB, and Redis.

Supported Databases

Mail Server Check

Comprehensive mail server health monitoring with security scoring. Checks SMTP, IMAP, POP3, DNS email records, blacklist status, and SSL certificates.

Features

• SMTP Verification — Port 25, 465 (SSL), 587 (submission)
• STARTTLS Support — Verify secure connection upgrade
• Open Relay Detection — Security test for misconfigured servers
• IMAP/POP3 Checks — SSL ports 993/995, verify mailbox access
• SSL/TLS Certificate Validation — Expiry, TLS version, cipher strength, chain validation
• Reverse DNS (PTR) — Validate server IP has proper reverse DNS
• Blacklist Monitoring — Check against 6 major RBL services
• DNS Security — SPF, DKIM, DMARC validation
• Scoring System — 0-100 score with A/B/C/D/F grades

SSL/TLS Certificate Monitoring

For each protocol (SMTP STARTTLS, IMAP SSL, POP3 SSL), we check:

• Certificate Validity — Valid, expired, or expiring soon
• Chain Validation — Verify the certificate chain is trusted
• TLS Version — Alert for insecure versions (TLS 1.0, 1.1, SSLv3)
• Cipher Strength — Alert for weak ciphers (<128 bit)
• Expiration Alerts — 30, 7, and 0 day thresholds

RBL (Blacklist) Servers Checked

We check your mail server IP against these Real-time Blackhole Lists:

DKIM Selectors

If you don't specify custom DKIM selectors, we check these common selectors:

default, dkim, google, selector1, selector2, mail, k1, s1

You can specify custom selectors (comma-separated) for your domain, e.g., google,zoho,mailjet

Scoring System

Mail server health is calculated as a score from 0-100:

Grade Thresholds

Geo Monitoring for Mail

Mail checks with geo monitoring use a split execution model: geo agents test connectivity (SMTP, IMAP, POP3), while the central server runs DNS-based checks (SPF, DKIM, DMARC, PTR, RBL) once to avoid redundant queries. See Agents & Geo Monitoring.

Heartbeat Check

Passive monitoring for cron jobs, scheduled tasks, and batch processes. Your service pings a unique URL to report it's running.

How It Works

1. Create a heartbeat check and get a unique UUID
2. Your cron job/script pings the URL after successful execution
3. If no ping is received within the grace period, you get alerted

Schedule Types

Simple Interval

Expects a ping every N seconds. Best for jobs that run at regular intervals (e.g., every 5 minutes, every hour).

Cron Expression

Expects a ping at specific times defined by a cron expression. Best for jobs that run at specific times (e.g., daily at 3 AM, every Monday at noon).

Cron Expression Format

Common cron examples:

• 0 3 * * * — Daily at 3:00 AM
• */15 * * * * — Every 15 minutes
• 0 0 * * 0 — Weekly on Sunday at midnight
• 0 9 1 * * — Monthly on 1st at 9:00 AM
• 0 */4 * * * — Every 4 hours
• 30 2 * * 1-5 — Weekdays at 2:30 AM

Ping Endpoints

Measuring Job Duration

Use /start and success ping to measure how long your job takes:

#!/bin/bash
PING_URL="https://healthchecks.example.com/api/ping/abc123"

# Signal job start
curl -fsS "$PING_URL/start"

# Run your job
/path/to/backup.sh
EXIT_CODE=$?

# Send result with exit code
curl -fsS "$PING_URL/$EXIT_CODE"

Sending Output/Logs

You can send up to 100KB of output with your ping using POST. This is useful for capturing stdout/stderr from your jobs.

#!/bin/bash
PING_URL="https://healthchecks.example.com/api/ping/abc123"

# Run job and capture output
OUTPUT=$(/path/to/backup.sh 2>&1)
EXIT_CODE=$?

# Send result with output
curl -fsS "$PING_URL/$EXIT_CODE" -X POST -d "$OUTPUT"

import subprocess
import requests

PING_URL = "https://healthchecks.example.com/api/ping/abc123"

# Signal start
requests.get(f"{PING_URL}/start")

# Run job
result = subprocess.run(
    ["/path/to/backup.sh"],
    capture_output=True,
    text=True
)

# Send result with exit code and output
requests.post(
    f"{PING_URL}/{result.returncode}",
    data=result.stdout + result.stderr
)

$PingUrl = "https://healthchecks.example.com/api/ping/abc123"

# Signal start
Invoke-WebRequest -Uri "$PingUrl/start" -Method GET

try {
    # Run your task
    $output = & C:\Scripts\backup.ps1 2>&1 | Out-String
    $exitCode = $LASTEXITCODE

    # Send success/failure with output
    Invoke-WebRequest -Uri "$PingUrl/$exitCode" -Method POST -Body $output
}
catch {
    # Send failure
    Invoke-WebRequest -Uri "$PingUrl/fail" -Method POST -Body $_.Exception.Message
}

Run ID for Correlation

Use the ?rid= parameter to correlate start and end pings for the same job run:

RUN_ID=$(uuidgen | cut -c1-8)
PING_URL="https://healthchecks.example.com/api/ping/abc123"

curl -fsS "$PING_URL/start?rid=$RUN_ID"
/path/to/backup.sh
curl -fsS "$PING_URL?rid=$RUN_ID"

Next Steps

• Set up agents for remote monitoring
• Configure notifications for your checks
• Understand the dashboard and charts
• Set up maintenance windows