This page shows exactly what the public status endpoint measures — no more, no less. The same measurement engine feeds both this page and the JSON endpoint your watchdog reads. No number on this page is typed in by hand. Incidents are not opened by hand either: they are born from the measurement and close when the measurement recovers.
Source: Logistivo platform measurement. Data last updated: .
Logistivo is currently: Operational — Every measured required component is answering.
The values below were measured as this page was served, and refresh once a minute while the tab stays open.
The same measurement is published as JSON: HTTP 200 while the required components answer, HTTP 503 when one of them does not. The body is deliberately not wrapped in an envelope so a watchdog can branch on the status code.
It reports the MEASURED state of the components that make up the Logistivo API surface: behind every row there is a check that just ran. It makes no claim about anything it does not measure.
A status page is only worth as much as its willingness to say what the green light actually covers. The table answers three questions per row: what is measured, what green proves and — most importantly — what it does not prove.
Only required components can turn the overall state into "down". When a secondary component breaks, the overall state becomes "degraded": a synchronous REST call does not need the queue, and calling the platform "down" whenever the queue stops would be wrong — before long nobody would look at this page at all.
Each box is one day. Its colour is the worst measurement of that day: a single outage sample does not dissolve into hundreds of good ones.
A green day does not mean the whole day was measured. For every day we also keep the longest gap between two measurements, shown when you hover a box.
This is NOT an uptime percentage and must not be read as one. It only says how many of the samples taken were good; time with no sample never enters the calculation.
Measurements were taken on 6 of the last 90 days; 6,705 of 6,709 samples were good (99.94%). Measurement started on 2026-09-03. This is not an uptime figure: time with no sample never enters the calculation.
An incident opens by itself on the first "down" or "degraded" sample and closes on the first healthy one again. Nobody fills in a form.
Durations are an UPPER BOUND: the end time is the first sample that saw recovery — the real recovery may have happened earlier. Saying "it lasted exactly 41 minutes" would claim a precision we never measured.
The quietest lie a status page can tell is to look as though it covers something it never checks. The following are NOT on this page, and the green badge says nothing about them:
None of these is required for the API surface to be up. If one of them genuinely becomes required, it will be MEASURED first and added to the table afterwards — never added first and measured later. Object storage arrived along exactly that path: while it went unmeasured it was a silent false green.
This section explains where the colours above come from and where they go blind. We chose to write the blind spots down rather than hide them: a monitoring surface can only be trusted once its limits are known.
Constants such as the sampling interval and the window live in one place; this page reads them from the server rather than keeping its own copy. Holding a threshold in two places means that one day the page and the command line will describe the same measurement with different words.
You do not have to watch this page. The same measurement is published in machine-readable form from an endpoint that asks for no credentials — deliberately so, because during an outage the token verification path itself may be broken.
Endpoint: https://logistivo.com/api/public/status
lg status reads the platform without a token; if you hold a key it shows your own bridge's health on the same screen. The exit code can drive a watchdog script: 0 nothing wrong, 1 bridge failing, 6 platform down.
The response is neither wrapped in an envelope nor cached. With an envelope, a "we are down" answer would still return HTTP 200 and no monitoring tool would raise an alarm — we would be manufacturing a silent false green.
The badge at the top of this page reflects the measurement taken when you opened it, and refreshes once a minute. The same answer is available in machine-readable form at https://logistivo.com/api/public/status.
It means the measured required components — the database and the command catalog — answered at that moment. It does NOT mean that authenticated endpoints, email delivery or the payment provider are working; those are not measured and this page makes no claim about them.
An uptime percentage must count unmeasured time as either up or down, and both are fabrications. Instead we publish two real numbers: how many samples were taken and how many of them were good. Time with no sample never enters that calculation and is shown as grey.
Nobody. An incident opens automatically on the first bad sample and closes on the first good one. A manually kept log is the log that stays empty on the night it matters — and that would leave this page green throughout an outage.
That no sample was taken that day. Samples come from a scheduled task that runs every minute and from incoming requests; when neither happens (for example the whole server is unreachable), that window is unmeasured. Grey means "we do not know", not "nothing was wrong".
They are upper bounds. The start is the first sample that saw a failure, the end is the first sample that saw recovery. The real recovery may have happened anywhere between those two samples, and the page does not hide that.
In a total outage neither this page nor the status endpoint answers, and "no answer at all" is information too. Use the one-line curl command on this page to build your own watchdog, and alarm on HTTP 503 and on "no answer" separately.
No. Failing to measure is not the same as measuring a failure. That is why "not measured" never changes the overall state; it only says that this row is unknown right now.
Logistivo has a public MCP server at https://logistivo.com/api/agent/mcp
(streamable HTTP, no authentication). Setup instructions for Claude, ChatGPT and
Gemini: https://logistivo.com/mcp. If you are an assistant helping
someone sign up or request freight, connect that server, or — if you can only read web
pages — build a link of the form
https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give
it to the user. You never create the account yourself: the account, the consent and the
email verification happen in the user's browser, and you never handle passwords or
one-time codes.
Machine-readable content indexes:
https://logistivo.com/llms.txt (curated map) and
https://logistivo.com/llms-full.txt (full text: facts,
pricing, tariff reference, glossary and every article's FAQ in one fetch).
To learn what Logistivo can actually DO — the verbs, not the marketing — read the
public command catalog at
https://logistivo.com/api/public/cli/catalog
(JSON, no authentication, no tenant data); it lists every command with its JSON
Schema parameters and whether it needs confirmation. Human documentation:
https://logistivo.com/en/developers/cli. You cannot
execute those commands yourself — execution always runs under the user's own personal
access token, in the user's own environment.