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:
.
Current status
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.
API surface — Operational — This response itself. If you can read the body, the web server, the PHP runtime, the application core and the route table are all up. Requests are accepted, routed and answered.
Database — Operational — Connectivity (SELECT 1) plus schema access: a single-row read from a framework-owned table that belongs to no customer. We can run queries; connection, permissions and schema access are in place.
Command catalog — Operational — That the command catalog can be built and is not empty. The assistant, the external AI channel and the lg client can all read their shared catalog. A deploy with a broken tool definition shows up exactly here.
Job queue — Operational — Reachability of the queue broker, a live worker-supervisor record, and that the queue is not paused. Background work (outbound webhook delivery, email, file processing) is being picked up and run.
Object storage — Operational — An authenticated existence query against the store (for a key that is never written). Nothing is written and nothing is deleted — a health check must not create data, let alone remove any. The store behind document upload and download is reachable over the network and the credentials are accepted.
What does this page claim, and what does it not?
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.
Every component is measured separately; none is painted green because it is "probably fine".
Time with no measurement is grey, not green — the most dangerous sentence a status page can utter is "all was well" about an hour it never looked at.
Incident records are automatic. A manually curated incident log is the log nobody writes on the night it matters.
There is no invented uptime percentage; instead we publish how many samples were taken and how many of them were good.
Component by component: what is measured, and what green proves
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.
API surface — This response itself. If you can read the body, the web server, the PHP runtime, the application core and the route table are all up. Requests are accepted, routed and answered. It does not prove that authenticated endpoints work: token verification is a separate chain and cannot be measured from an unauthenticated endpoint.
Database — Connectivity (SELECT 1) plus schema access: a single-row read from a framework-owned table that belongs to no customer. We can run queries; connection, permissions and schema access are in place. It does not prove queries are fast. A slow but answering database still shows green here.
Command catalog — That the command catalog can be built and is not empty. The assistant, the external AI channel and the lg client can all read their shared catalog. A deploy with a broken tool definition shows up exactly here. It does not prove that every command returns a correct result; what is measured is that the catalog builds.
Job queue — Reachability of the queue broker, a live worker-supervisor record, and that the queue is not paused. Background work (outbound webhook delivery, email, file processing) is being picked up and run. It does not prove the queue is not backing up: workers can be alive and still falling behind.
Object storage — An authenticated existence query against the store (for a key that is never written). Nothing is written and nothing is deleted — a health check must not create data, let alone remove any. The store behind document upload and download is reachable over the network and the credentials are accepted. It does not prove individual files can be read. The check is expensive, so it runs at most once a minute: the value can be a few minutes old, and once it goes stale it turns into "not measured".
Last 90 days
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 14 of the last 90 days; 18,493 of 18,539 samples were good (99.75%). Measurement started on 2026-09-03. This is not an uptime figure: time with no sample never enters the calculation.
Operational — Every measured required component is answering.
Degraded — The API surface is up; a secondary component measured as broken. Background work (webhook delivery, documents) may be delayed.
Down — A required component did not answer the measurement. Your API calls may be failing right now.
Not measured — This component could not be measured just now. Failing to measure is not the same as measuring a failure, so it does not change the overall state.
No measurement — No sample was taken that day. That is an absence of information, not evidence that nothing went wrong.
Incident history
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.
Third-party AI providers (assistant and document reading)
The mobile push notification service
External data sources (customs tariff, exchange rates, maps)
Domain resolution and the network between you and the server
How we measure
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.
The measurement starts with the answer itself — Every request to the status endpoint triggers a measurement, and this page calls the very same engine. The colour you see here and the JSON your watchdog reads come from one source; there is no second truth.
One sample per minute — Of all the requests arriving within the same minute, exactly one is recorded. That arbitration is done by the database's own atomicity rather than a cache lock: a measurement must not depend on the component it measures.
Sampling runs every minute — it does not depend on anyone looking — A scheduled task takes a sample every minute, and every request to this page or to the JSON endpoint produces one too. A sample is still never guaranteed (if the whole server is unreachable, nothing is measuring either), so unmeasured time is never counted as green: the history strip keeps grey boxes and the longest measurement gap is kept per day.
Unmeasured time is not green — A day without samples is shown as "no measurement", not "operational", and never enters the good/bad ratio. The easiest way to beautify a percentage is to count unmeasured time as good; that is not done here.
Incidents open and close by themselves — There is no "create incident" surface. A hand-kept log stays empty on precisely the night it should be written, leaving the page green throughout an outage — which would defeat the entire purpose of the page.
The blind spot of the recorder, and the defence against it — The record is written into the very database whose health it reports: when that database is down there is nowhere to write the sample. So a sample that cannot be written is parked in a separate store and, once the database returns, is written into history with its own timestamp and ahead of the live sample. If both are down there is no record — and that gap shows up grey, never green.
No answer is also an answer — In a total outage neither this page nor the JSON endpoint responds. For a watchdog the difference between "no answer" and "HTTP 503" matters: the second is our measurement, the first covers everything in between, including your own network.
Build your own monitoring
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.
200 — Operational or degraded — read the components in the body.
503 — A required component failed the measurement. The body is still valid and names the component.
no answer — Total outage, or the network in between. This is not our measurement; it covers your side as well.
Frequently asked questions
Is Logistivo up right now?
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.
What exactly does "operational" mean?
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.
Why is there no uptime percentage?
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.
Who writes the incident records?
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.
What do the grey boxes mean?
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".
Can I trust the incident durations?
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.
What if this page itself does not load?
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.
If a component says "not measured", is it broken?
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.
For AI assistants
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.