QyzarQyzar/

Docs

Dashboard

Start

  • Overview
  • Quick start

SDKs

  • Browser SDK
  • Server helper

Guides

  • Client tokens
  • Verify sessions
  • Rate limiting
  • Uptime & status

API

  • API basics
  • HTTP routes

~5 min read

Uptime & public status

Run synthetic checks from Qyzar’s proxy pool, publish a public status page, and tune what HTTP codes count as healthy — including sites protected by Qyzar traffic rules.

Public status page (runtime page)

Your public status page (sometimes called the runtime status page) is hosted at https://status.qyzar.eu/<your-name>. It shows aggregate uptime and each monitor without requiring login.

  1. Open the dashboard: Dashboard → [your project] → Uptime.
  2. Claim a globally unique status name (e.g. acme). This becomes the URL segment — status.qyzar.eu/acme.
  3. Add one or more uptime monitors (URLs to probe).
  4. Share the public link. The page refreshes about every 15 seconds from live check data.

You can also see the claimed URL under Project → Settings → Public status page name.

Where to configure monitors

  • Dashboard: /dashboard/project/<projectId>/uptime
  • Public page: https://status.qyzar.eu/<status-slug> (read-only)
  • API: POST /projects/uptime-monitor, PATCH /projects/uptime-monitor, GET /projects/uptime (HTTP routes)

Expected response code overrides

By default, a check is UP when the response status is one of: 200, 201, 204, 301, 302, 303, 307, 308 and TLS is valid (for HTTPS). Timeouts and connection errors are always DOWN.

Override this per monitor with a comma-separated list of HTTP status codes. Only codes in your list count as UP — useful when a healthy endpoint returns 403, 401, or a custom maintenance code.

{
  "projectId": "…",
  "url": "https://api.example.com/health",
  "expectedStatusCodes": [200, 403],
  "userAgent": "Qyzar-Uptime/1.0"
}

Leave expectedStatusCodes empty (or omit it) to use the default list above.

Allow the probe User-Agent (Qyzar-protected sites)

Checks are sent through Qyzar’s outbound proxy with a configurable User-Agent (default Qyzar-Uptime/1.0). If the URL you monitor is behind Qyzar verification or traffic rules, probes can be challenged or blocked like any other request unless you explicitly allow them.

  1. Note the Probe User-Agent on your monitor (dashboard form or API userAgent field).
  2. Open Dashboard → [project] → Traffic Rules.
  3. Add a User-Agent rule with action allow and pattern matching your probe, e.g. Qyzar-Uptime (substring) or ^Qyzar-Uptime/ (regex).
  4. Prefer a dedicated health URL (e.g. /health) that returns your expected status without running the full browser SDK — then allow only that path + UA if possible.
{
  "rules": [
    {
      "id": "allow-uptime-probe",
      "name": "Uptime synthetic checks",
      "type": "userAgent",
      "action": "allow",
      "values": [
        { "kind": "userAgent", "pattern": "Qyzar-Uptime", "match": "substring" }
      ]
    }
  ]
}

See Rate limiting & rules and backend PROJECT_RULES.md for the full rules JSON shape (legacy userAgent array is still supported).

Checklist

  • Status slug claimed on Uptime before adding monitors.
  • Expected status codes match what your endpoint actually returns when healthy.
  • Probe User-Agent allowed in Traffic Rules if the target is Qyzar-protected.
  • Proxy registry configured on the API server (backend/data/proxies.json) for outbound checks.