90 days of status. One bar per day, per component.
Every minute, the instance records the verdict GET /api/v1/status publishes on the work it does in the background. Each bar is one day, in the colour of its worst moment.
Right now
Healthy: 4 of 4 Not measured while the work is under way, measured again as soon as it ends. Measured at most 30 s before .
The last 90 days
UTC days- Healthy
- Degraded
- Down
- Maintenance
- No data
The instance's metronome: it starts every background task on time.
100%uptime
Its heartbeat, and each task it starts: counting outbound traffic, checking custom domains, retention, emptying the recycle bin, reconciling storage and recording this history.
Your uploads and links do not go through it. What stops with it: outbound traffic is no longer counted, retention and the recycle bin wait, quotas are no longer recalculated. It is the only component whose stopping turns the verdict to “Down”.
“Degraded” when a task is late or its last run failed. “Down” when its heartbeat has been silent for 3 minutes, which is also how a gap in this history is counted.
The work queued after an upload, such as compressing videos and sounds.
100%uptime
How long queued jobs wait, wherever the instance can count it, and the jobs that ran out of attempts.
Your uploads are accepted and served as usual. A video or a sound is served in its original format, at the same URL, until its compressed version arrives.
“Degraded” when the oldest waiting job has waited too long, a worker dropped a job, or too many jobs ran out of attempts in a day. “Down” only when the instance could not measure itself.
Videos and sounds waiting for their compressed version.
100%uptime
Files still processing more than 60 minutes after their upload, with nothing left in line to finish them.
The original file is still served at the same URL: your players see or hear it, just heavier than planned.
“Degraded” as soon as one file is still processing 60 minutes after its upload with nothing left in line for it. “Down” only when the instance could not measure itself.
Erasing the files you deleted.
100%uptime
A deleted media spends 7 days in the recycle bin, then its files are erased. This component checks that erasing keeps up.
Nothing changes on your side: your quota already counts that space as freed. The delay only concerns the instance's disk.
“Degraded” when more is due in the recycle bin than one night erases. “Down” only when the instance could not measure itself.
Egress reading
Counting the bytes delivered to your players.
Nothing was recorded for it here, so there is nothing to draw.
Recorded every minute since 29 Oct 2026. A bar is a UTC day, in the colour of its worst state.
Uptime is the share of the measured minutes spent operational: a degraded or down minute counts against it, a minute nobody measured or a maintenance minute counts neither way.
A declared maintenance window is drawn in its own colour, never as an incident: background work is paused on purpose while it lasts, and resumes by itself afterwards.
The recording runs on the scheduler. While the scheduler is stopped nothing can be recorded, and that silence counts as the scheduler being down, unless a declared maintenance window covers it.
What this page does not probe: the upload API, file delivery, the dashboard and its live feed are not checked from the outside. If this page loads, the server serving it is answering.
Know before your players do. With your own probe.
-
Healthy "ok"
Everything running in the background is keeping up.
-
Degraded "degraded"
Something in the background is falling behind. Uploads and delivery do not depend on it.
-
Down "down"
The scheduler has stopped, or the instance could not measure itself.
In data.health.components, scheduler, queue, processing, sweep and egress each carry one of these same three states, with no queue name, count or error message. What the instance cannot measure is left out, never shown as "ok".
Your monitoring can ask the very address this page reads, with no API key. Point it at that JSON address rather than at this page: that is where the verdict lives.
Alert on data.health.state
The response stays HTTP 200 with "status": "ok" whatever the state: that code says the request succeeded, not that all is well.
One probe every 30 s is enough
The verdict is worked out again every 30 seconds at most. Asking more often returns the same answer.
{ "state": "ok", "components": { "scheduler": "ok", "queue": "ok", "processing": "ok", "sweep": "ok" } }
# Read the verdict, no key needed curl -s https://aperture-app.preview.moncompanion.cloud/api/v1/status \ | jq -r '.data.health.state' # ok, degraded or down: alert on anything but ok state=$(curl -s https://aperture-app.preview.moncompanion.cloud/api/v1/status \ | jq -r '.data.health.state') [ "$state" = "ok" ] || echo "Aperture: $state"
-- When the resource starts: warn the console -- if Aperture is falling behind PerformHttpRequest('https://aperture-app.preview.moncompanion.cloud/api/v1/status', function(code, body) if code ~= 200 then return end local state = json.decode(body).data.health.state if state ~= 'ok' then print(('[aperture] status: %s'):format(state)) end end, 'GET')
A problem this page does not show?
Keep the X-Request-Id header of the response in question: it points to the exact request in the instance's logs.