Status page

Liyagent measures its own availability and publishes it at /status. This is the platform's own uptime, not the ticket SLAs a service desk keeps.

What is probed#

The leader probes three components every TICKETIQ_STATUS_PROBE_INTERVAL_S seconds (default 60, from 15 to 3600):

A fourth series, platform, is the check in which every component passed. It is the number the SLA is judged on.

Each component's count of checks run and passed, and the seconds those checks vouch for, is kept per hour.

Uptime is time, not a count of checks#

Each check stands for the seconds since the check before it. Measurement runs from the first check ever (or the start of the look-back) to the last one.

• A late scheduler is not downtime. The scheduler runs a job on the first tick after it is due, so a 60-second probe runs every 60 to 65 seconds. A check vouches for the whole gap while it is at most two probe intervals.
• A missed check is downtime. After a longer silence, a check vouches for one interval only: the rest was not watched, and a process that is down cannot record that it is down. Once checks have stopped for longer than two intervals, the silence up to now counts as down.
• A check that could not run is a failed check.

Every figure names the days it covers#

The page looks back at most 90 days, but no figure claims more history than exists. Uptime, each component and the SLA each say exactly which days they cover: "since 2026-11-05 (3 days measured)". On a new instance that is a few days, not 90.

• Daily bars cover measured days only, each a UTC day's measured seconds against those its passing checks vouch for.
• Components show "No data yet" for uptime until their first check, and a component with no probe reads "Not measured yet".
• The SLA is judged over TICKETIQ_STATUS_SLA_WINDOW_DAYS (default 30) against TICKETIQ_STATUS_SLA_TARGET (default 99.9). Until the window is fully measured, the page says the figure covers fewer days than the target is judged over. It shows the downtime used against the error budget, the downtime the target allows over the window.

The public page#

/status is a server-rendered page with no script, and GET /api/status returns the same content as JSON. Both are rate limited and marked noindex.

TICKETIQ_STATUS_PAGE_PUBLIC (default true) decides whether they answer anyone. Set it to false and both return 404; the Platform page still shows the instance owner the same and more.

The public view carries states and percentages only: never an error, a host or a version, and not who posted an incident update.

The JSON#

Percentages are null for a component never measured.

curl -s https://<host>/api/status | python3 -m json.tool | grep -A12 '"sla"'

Incidents#

Incidents are the operator's to post. Open Settings › Platform (/platform) and choose Post an incident:

An incident starts as investigating. Choose Post an update to move it through identified, monitoring and resolved; resolved closes it, and a resolved incident takes no more updates (open a new one). An incident holds at most 100 updates.

An open incident with major or critical impact shows its components as degraded; a critical one makes the headline an outage. A maintenance incident shows maintenance.

The platform routes also need a read scope across every tenant. Incidents are audited as platform.incident.open and platform.incident.update.

Next steps#

• Crash resume and high availability
• Telemetry