Live checks
- Web app
- API
- Database
- Job queue
A lime dot means the check passed a moment ago. A violet dot means it did not. A grey dot means the check could not run: the database and the queue are probed through the API, so when the API is silent nothing here knows their state. There is no percentage anywhere on this page, because nothing in the system keeps a history to average.
What is being checked
Your browser calls two public endpoints and reads what comes back.
| Check | Endpoint | What a pass proves |
|---|---|---|
| Web app | — | Nothing is probed. If this page rendered at all, the web container served it. |
| API | /healthz | The API process is running, and reports how long it has been up. That clock resets on every deploy and on any restart. |
| Database | /readyz | PostgreSQL answered a SELECT 1 within three seconds. |
| Job queue | /readyz | Redis answered a PING within three seconds. |
The request goes to this site’s own origin, which passes it through to the API inside the machine, so the last hop never touches the public internet. The same two endpoints are public if you would rather check them yourself: /healthz and /readyz.
Both endpoints are unauthenticated and both are exempt from the API’s rate limit, so you can refresh this as often as you like. The database and queue probes run at the same time and each gets three seconds; a slow answer counts as no answer.
The board re-checks every thirty seconds while this tab is in front, and once more the moment you come back to it. It stops while the tab is hidden. Nothing along the way is cached. The date at the top of this page is when this text was last written — the board carries its own timestamp.
What isn’t checked
The readiness endpoint probes two dependencies. That is the whole list. Everything below is real, can fail on its own, and would not show up here.
- Object storage. Your images live in a Wasabi bucket in the ap-southeast-2 region, not on the application server. Nothing on this page probes it.
- Malware screening. Files are streamed to ClamAV, and screening is fail-closed: an unreachable scanner fails the file rather than admitting it unscanned. What that means differs by path. An archive entry is scanned before it is written to the bucket at all, so a scanner outage means an import brings in nothing. A file uploaded through a signed URL is in the bucket before we can scan it, so the upload is still accepted — the analyse worker then deletes it and marks the asset failed shortly after it lands. Files above the scanner’s 50 MB ceiling are recorded as unscanned rather than blocked; the 50 MB per-file upload limit is what keeps that from mattering. An outage therefore shows up as failed assets rather than refused uploads, with every check above still green. Security has the detail.
- The processing pipeline. Image work and inspection run in separate containers that take jobs off the queue. If they stop, the API still answers and Redis still replies — jobs simply stop moving.
If every check above passes and something still is not working — an upload that will not complete, a job that will not start — please tell us. That is exactly the kind of failure this page cannot see. Email hello@jeani.ai.
Incident history
We do not publish one yet. There is no incident log in the product and no external monitor recording outages behind this page, so a history here would be something we typed rather than something we measured. Until that exists, this page answers for right now and nothing else.
If an outage affects your work we will email the address on your account once we can. The mailer runs on the same machine as everything else, so that message follows the recovery rather than the outage. There is no subscribe-to-updates list. To report a problem, or to ask what happened, email hello@jeani.ai.
Scheduled maintenance
There are no maintenance windows. Jeani runs one container per service on one machine, so deploys are not rolling: the API container restarts, database migrations run as it boots, and requests fail until it passes its readiness check again. Deploys are not announced in advance.
The two workers are given three minutes to finish the job they are on before they are stopped, so most in-flight work simply completes. A job still running at three minutes is killed, and the queue hands it to a worker again once its lock expires — it starts over rather than resuming, but it is not lost.
Two jobs do run to a fixed schedule, and neither takes the service offline. A database backup starts every night shortly after 03:20 Sydney time, against the live database. A restore check starts every Sunday shortly after 05:00, restoring the newest backup into a throwaway database beside the live one and failing if it will not come back. That failure is recorded on the server for us to read; nothing pages anyone automatically. Security has the detail.
Where Jeani runs
One dedicated server in OVHcloud’s Sydney datacentre, running Ubuntu 24.04. Caddy terminates TLS in front of it, and the web app, the API, the two workers, the malware scanner, PostgreSQL and Redis are all containers on that same machine. Your images are not: they sit in a Wasabi bucket in ap-southeast-2, the region Wasabi names Sydney, with versioning switched on, so an overwrite or a delete leaves the previous version recoverable.
That is deliberately small and single-region, and it has an obvious consequence: there is no second region to fail over to. If the machine is down, Jeani is down — and this page will not load either, which is its own kind of answer.
Security covers how the machine is locked down and how backups work. Privacy covers what is stored and where. Section 7 of the terms says what we do and do not promise about availability: there is no uptime figure and no service level agreement.