Live availability is published at status.mercemur.com. Check it first when a request fails in a way your code did not cause: connection timeouts, 502, 503, or a sudden change in latency across every endpoint at once. A failure that is ours will show there before you finish reading your own logs.

​
What is monitored

Fourteen checks run across five groups, each on its own schedule. They are grouped on the status page the same way they are grouped here, so a red badge maps to a row below.

​
Shopping

The checkout check asserts that the payment provider list is not empty, not merely that the endpoint answers. That endpoint returns 200 with an empty list for a store with nothing connected, so a status-only check would stay green through exactly the failure this exists to catch.

​
Merchant tools

​
API and integrations

​
Public web

​
Certificates

Certificates renew automatically. These three exist to catch renewal having quietly stopped, which is invisible until the day it is not.

​
Why some checks pass on a 4xx

Two checks treat 401 as the healthy state, and one treats 403 that way. This is deliberate and worth knowing before you read the JSON feed and conclude something is broken. A 401 from Public API and Admin API proves more than a 200 from a health endpoint does: routing reached a real route and the auth gate refused an anonymous caller. A 200 there would mean the gate had disappeared. A 404 or 502 would mean routing had. The Media CDN check passes on 403 for the same reason, since the edge refuses a bucket listing and that refusal proves both the edge and its storage backend answered. So if you consume the feed, judge a check by its success field, never by the HTTP status you find inside it.
A slow answer fails a check outright. Where a row above names a time budget, exceeding it turns the check red even though the request returned 200. Latency is treated as an outage, not as a warning.
The API check reads the health endpoint’s status field only. It deliberately does not publish the build revision.

​
Reading it from code

The page has a JSON feed, so a monitor of your own can consume it without scraping HTML.
Each entry carries a group, a name, and a results array holding the last 50 checks, newest last. A result carries success, a timestamp, the HTTP status, the duration in nanoseconds, and a conditionResults array naming every condition that was evaluated and whether it held.
Treat success on the last element of results as the current state, and judge it by that field rather than by the status beside it. Polling faster than once a minute gains you nothing: the quickest checks run every 60s and the slowest every hour, so a tighter loop returns an answer that has not changed.

​
What it does not tell you

The page reports whether Mercemur is serving requests. It does not report the health of your own store’s data, a specific order, or a third party you have connected such as a payment provider or a carrier. A green status with failing requests points at authentication, scopes, or the request itself. Start with the error codes reference.