---
title: "System status | Veldarium"
canonical: https://www.veldarium.com/status
html: https://www.veldarium.com/status
description: "Public request-time checks, current component state, and the monitoring boundaries behind the result."
last_updated: 2026-10-12
representation: registry-derived Markdown
---

# System status

> Public request-time checks, current component state, and the monitoring boundaries behind the result.

The live snapshot is [https://www.veldarium.com/api/status](https://www.veldarium.com/api/status). This document is static and checks nothing.

## States

- **Operational:** Current evidence that it did its job.
- **Degraded:** Current evidence that it works only partly: slow, failing some work, or behind.
- **Unavailable:** Current evidence that it failed.
- **Stale evidence:** The last evidence is older than its freshness window, so it says nothing about now.
- **Unknown:** A check exists but produced no usable evidence: nothing has reported, or the record could not be read.
- **Not monitored:** Nothing in this deployment observes it. Silence is not health.

The snapshot draws one cell per capability: a filled disc where it is operational; a triangle where it is degraded or unavailable; a hatched square where it is stale evidence, unknown or not monitored.

## Capabilities

- **Public application:** This deployment served the status request. One successful request is not an availability percentage or a latency target.
- **Primary datastore:** A bounded read-only query, and whether the schema this build expects has been applied. Checked only where the deployment enables it. Reachability is not a durability or backup guarantee.
- **Authentication boundary:** The session-signing secret signs and verifies, refuses a forged signature, and the datastore that sessions live in is operational. No real sign-in is attempted. Identity-provider sign-in is not checked.
- **Deterministic readiness engine:** The deployed readiness engine returns the expected READY, NOT READY and CANNOT ESTABLISH verdicts on three synthetic cases. Synthetic records only. This is not a governed answer on anyone’s records.
- **Background processing:** Whether a worker has reported recently, and whether queued work is being processed rather than waiting. A worker that reports is alive; only processed work shows it is useful. A worker that never reported reads as unknown, not as healthy.
- **Incident record:** Whether the incident record could be read for this page. An unreadable record is unknown, never "no incidents".
- **Governed-answer retrieval:** Nothing. The answer path writes records, so no synthetic probe exercises it. Repository tests do not establish live availability.
- **Object storage:** Nothing. No read or write canary exists. Storage health is not inferred from application availability.
- **Running build:** deployment metadata. The commit and the time the build was compiled, from the build clock; not the time it was deployed or promoted.
- **Incidents:** customer-visible incidents an operator recorded, active and resolved in the last 90 days. No incident record is connected in this deployment, so no incident history is claimed. The incident record could not be read. This is not a statement that there are no incidents.

Checks run when this page or /api/status is read, at most once a minute per instance, and the worker reports itself. Nothing observes the site between reads, so this is not an independent uptime monitor, an availability history or a service-level commitment. Alert ownership and a published response policy are not connected to it.

## Contact

To discuss a first VeldBuild deployment, or the company: [chris@veldarium.com](mailto:chris@veldarium.com). Name the release decision your team rebuilds by hand. Do not send confidential information in the first message.

## Sitemap

- [Full site map](https://www.veldarium.com/sitemap.md)
- [Machine context](https://www.veldarium.com/llms.txt)