SiroPing
Open App
Community · Pro · Business

HTTP Monitoring

Monitor the availability, response time and content of a website or HTTP API. Includes basic auth, expected content, login-form checks and SSL.

HTTP Monitoring

Monitor a website or HTTP endpoint for availability, response time, content correctness and SSL health.

Create a monitor

  1. Monitors → New HTTP Monitor.
  2. Fill in:
Field Meaning
Name Human-readable, e.g. "Client A — main site"
URL https://example.com (supports Basic Auth in the URL too)
Interval How often to check (minutes)
Timeout Fail if the response takes longer
Expected status e.g. 200; a different status = Down/Warning
Expected content A string that must appear on the page (see below)
  1. Save. The first check runs within the interval.

Statuses

Status Meaning
Up Responded OK, matches expected status/content, SSL fine
Warning 4xx/redirect, expiring SSL, or missing expected content
Down Connection/timeout error or wrong status after retries

Basic authentication

If the site requires a login, enable Basic Auth and enter username/password. The password is stored encrypted at rest.

Expected content check

Catches the classic "HTTP 200 but it's actually an error/login page": enter a string that must appear in the body (e.g. the site's <title> or a key word). If it's missing → Warning.

Defacement detection (forbidden content)

The reverse: alert when a string appears that should never be there — the signature of a hacked site (injected casino links, hacked by banners, gambling keywords). Enter Forbidden content (plain text) and optionally a forbidden regex. A hit → Down with the surrounding snippet in the message, so you can judge instantly.

Pro feature. Tips: use distinctive strings (casino, rikvip, hacked by); avoid common words that cause false alarms. Like expected content, the page body itself is never stored — only the matched snippet.

Slow threshold (response-time warning)

Set Slow threshold (ms): a healthy response slower than this becomes a Warning (perf:slow) instead of silent green. Pro feature. On jittery networks prefer a generous threshold (e.g. 150% of your normal p95).

Login-form check (sites behind a login page, e.g. ERP)

For sites where the static login page returns 200 even when the backend/DB is down, enable "Log in before checking":

  1. Login URL, Username, Password.
  2. Optional Check URL after login — a page only reachable after authentication.
  3. Use Test login to verify credentials before saving.

SiroPing logs in (via headless Chromium), then checks the target page — so a DB failure behind the login is reported as auth:login_failed / http:500 instead of a false Up.

Privacy & data handling

A behind-login check does authenticate and read the target page, so it is worth being precise about what happens:

  • SiroPing reads one URL only — the target page you configured. It does not crawl or browse the rest of the application.
  • Page content is never stored. Each check reads the page to verify status and the optional expected marker, then discards it. The check record keeps only: status, response time, HTTP status code and a boolean "expected content found" — never the page body.
  • Credentials are encrypted at rest (Fernet) and never written to logs.
  • It runs on your server. Because SiroPing is self-hosted, the login credentials and any content the check reads never leave your own infrastructure — unlike a SaaS monitor, which would send them to a third-party cloud.
important

Best practice for client sites — use a **dedicated read-only monitoring

account**, not a real user's account. Point the check at **one narrow URL** (e.g. a healthpage or API endpoint) rather than the whole application, and disclose the monitoringarrangement in your service agreement. If a client is not comfortable with anybehind-login access, leave this option off and monitor with plain HTTP or a[Heartbeat](./heartbeat/) ping instead.

Example — read-only health check

Login URL:    https://erp.example.com/login/
Username:     monitor-user (read-only role)
Check URL:    https://erp.example.com/health/  # one endpoint, not the whole app
Expected:     "status":"ok"

SiroPing verifies the backend is really alive — and keeps nothing but the status.

API monitoring

The HTTP monitor works for HTTP APIs, not just websites. Configure:

  • Method — GET, POST, PUT, DELETE or PATCH (default GET).
  • Request headers — one per line, Key: Value (e.g. Authorization: Bearer <token>, X-API-Key: <key>). Values are stored encrypted at rest.
  • Request body — raw body for POST/PUT/PATCH (Content-Type defaults to application/json).
  • Expected status / expected content — check the API returns the right code and a marker string from the JSON body (e.g. "status":"ok").
tip

For plain GET endpoints with no custom headers, SiroPing uses the normal web check

(headless browser). As soon as you set a method other than GET, or add custom headers, itswitches to a lightweight direct HTTP request — fast and no browser overhead.Basic Auth is still available alongside custom headers (added as an `Authorization: Basic …`header unless you set one yourself).

Example — POST a JSON payload:

Method:  POST
Headers: Authorization: Bearer abc123
         Content-Type: application/json
Body:    {"project":"client-a"}

Monitor becomes Up when the API returns HTTP 200 and the body contains your expected marker.

Timeout, cooldown and grace

  • Timeout — per-check limit; slow sites don't become "Down" by mistake.
  • Cooldown — minimum gap between two alerts (no alert spam).
  • Three consecutive failed checks open one incident (dedup).

SSL monitoring

SSL is checked as part of the HTTP capability — see SSL Monitoring.

Was this page helpful?