Uptime and availability
Every instance is checked the way a visitor reaches it: over HTTPS, through nginx, using the instance's own host name, once a minute.
That choice is the whole point of the feature. A check that asked the container whether it was running would answer yes while a broken certificate, a missing nginx site or a firewall rule left the instance unreachable to everybody. This one fails when your customers cannot get in.
The probe asks for /web/login: cheap, always present, and never a redirect loop.
The five verdicts
| Verdict | What it means | Counts as |
|---|---|---|
up | The instance answered as expected | Available |
degraded | nginx answered, but with a gateway error - the site is up and Odoo is not | Unavailable |
down | Nothing answered | Unavailable |
refused | The instance's own firewall turned the probe away | Neither |
unknown | Nothing has been measured yet | Neither |
refused is the verdict worth understanding. The check gets through an instance's firewall rules,
whether they list addresses or name host names, countries or continents, and its
pre-authentication by itself, so a protected instance reads up
like any other. What still refuses it is a path the rules close to everybody without
asking anything, such as one whose only rule admits nobody: the site answers the check as it answers
every caller there, with the instance's On block answer, and that answer reads refused. That
instance is working exactly as configured, and counting it as downtime would make a correctly
locked-down instance look permanently broken. It moves no counter and it is left out of the
availability denominator entirely.
Only a refusal by the instance's own firewall reads refused: the site marks its refusals for the
probe, and no visitor ever sees that mark. When Odoo itself answers 401 or 403, for example because
a module asks for a sign-in on /web/login, the instance answered, so it reads up and its
availability is measured like any other. The same holds for visitors: a page Odoo refuses, such as
an attachment someone may not open, reaches them with Odoo's own status, 401 or 403, not with the
firewall's On block answer. The firewall's answer is only ever given to a caller the firewall
turned away.
The check asks once a minute and once only: a site that closes the connection without answering is not asked again in the same minute.
An instance with no host name of its own cannot be checked this way at all. There is nothing to resolve and nothing for nginx to match. Those instances are named as unmonitored rather than shown as healthy.
Three down, two up
An outage opens after three consecutive failures and closes after two consecutive successes.
A single network hiccup is therefore not an alert. Paging on one trains an operator to ignore the alerts, which costs more than the hiccup ever did.
Both events are alerting events - instance.http.down and its paired
resolution - so they follow whatever rule you have set, and the recovery goes to the same channel
that carried the outage.
What you see
On an instance's own page: availability over the last 24 hours, 7 days, 30 days, 90 days or year, the latency of the last check, the days left on the certificate, and the outages themselves with the time each began and ended.
For every instance at once, in one call:
GET /api/v1/server/uptime
Or from the command line:
pelmo$ ohm server uptime --server pelmopelmo$ ohm instance uptime --server pelmo --instance fanes --period 30dBoth take --period as one of 24h, 7d, 30d, 90d or 1y.
How long the history lasts
| Resolution | Kept for |
|---|---|
| Five-minute buckets | 14 days |
| Daily buckets | 400 days |
The fine rows are compacted into daily ones nightly. A year-long availability figure is therefore real rather than extrapolated, without keeping a year of minute-by-minute rows to produce it.
Certificates become alerts, not chores
A certificate inside its warning window raises an alert once a day - critical under three days - and resolves by itself when the renewal goes through.
The defaults are 14 days for the warning and 3 for critical. A renewal that works is silent; you hear about the one that did not.
A filesystem filled past Usage warning (%) or Usage critical (%) under Configuration (80 and 90 by default) works the same way, and has to come back meaningfully below the line before it clears, so a disk sitting exactly on the boundary does not send a message every minute.
The alert comes once per filesystem, not once per directory, and names the server's directories
that live on it. On a server that keeps everything on one disk, a single alert reads / is
running low (instances, backup, archive and temp directories), and is nearly full and has room
again name them the same way.
Where the probe runs
It runs on the server the instances run on, so a single server is monitored without anything extra to install.
Turning it off
If you monitor from somewhere else already, switch it off with Api:Uptime:Enabled. See
Api:Uptime for that and the other uptime settings, and where they are set.
The current state and the events stay readable at every edition. The history behind the percentages is Performance and uptime history, a Professional capability: it is recorded whatever the license carries, but below Professional the page shows only where each target stands now, and an upgrade shows the past at once. Availability monitoring itself is not licensed; sending alerts off the server is.