Reading a panel's status page and health signals

A status page is supposed to answer one question: is the service working right now? Many answer a different question: is the website up? The difference matters when you are about to deposit, because a panel can serve a green page while its catalogue is three days old and its supplier queue is stuck.

This guide shows what a useful status page contains, how to read the timestamps and failure counts, and how to keep your own record when the panel does not publish one. It uses the public market tables on this site as an example of the signals, not as a claim that every panel publishes them.

A status page is a log, not a badge

A badge says "operational". A log says what was checked, when, and what happened. The first is a mood. The second is evidence. A useful status page has four parts: a timestamp for the last successful check, the component that was checked, the result, and a history that shows the result over time.

Without the timestamp, the page cannot be read. "Operational" at a moment is not the same as "operational" after an outage that nobody updated. Without the component, the page cannot be localised: a panel can be up while its order placement is down, or its catalogue can load while its supplier API is failing. Without the history, the page cannot show a pattern, and a pattern is what tells you whether a failure is a one-off or a habit.

Six signals

Signal	Where to find it	A healthy reading	A warning reading
Last successful sync	Status page or catalogue header	A timestamp inside the last day	No timestamp, or a date older than the crawl
Catalogue size trend	Service count on the catalogue page	A count that moves by a few rows	A large drop with no notice
Queue depth	Order page or status page	A depth that returns to normal	A depth that grows for days
Order success and failure	Status page or support	Failures named and dated	No failure count at all
Supplier health	Status page or support	A named layer, panel or supplier	"All systems" with no layers
Incident history	Status page	Dated entries with a resolution	A page that has never shown an incident

A status-page checklist. It contains no market figures and no supplier names.

The six signals are related. A queue depth that grows while the catalogue size falls is a supplier problem, not a website problem. A catalogue that has not synced while the order page still accepts orders is a panel that is selling from a stale list. The combination is more informative than any single green dot.

Reading timestamps

Start with the last successful sync. If the page says "operational" and the last sync is older than the order you are about to place, the page is describing a previous version of the service. The age is the signal, not the colour. A page that updates every hour is more useful than a page that updates every week, even if both say "operational".

In the market tables on this site, the last crawl finished on 7 November 2026, on the day this page was rendered. That timestamp is published with the figures, so a reader can tell how old the table is before using it. A panel's status page should give you the same courtesy.

Then read the last successful panel read. The last successful read in the market crawl was on the day this page was rendered. A panel that has not been read successfully for a week is not necessarily down, but it is not giving the crawl anything to confirm. The same logic applies to the panel's own status page: a component that has not reported is not the same as a component that reported success.

What the market crawl shows

When the market crawl has panel statuses, the table below aggregates them by status. It is a market-level view, not a panel-level one, and it contains no panel names. The point is to show what a status distribution looks like when it is read from a database rather than from a badge.

Status	Panels	Share
Active	32	100%
Read successfully	32	100%
Total panels	32

Read from the market tables when the page is rendered. Status labels describe the last read, not a permanent condition. Market edition: 7 November 2026.

Those four numbers are the kind of record a panel should publish about its own catalogue. Without them, a status page is a page that says "trust us" in a green font.

A failure is not automatically a bad sign. A panel can be blocked by a challenge page, rate-limited, or temporarily offline. What matters is whether the failure is named and dated. A named failure is a system that knows what happened. An unnamed green page is a system that has decided not to tell you.

Panel status versus supplier status

A panel is a layer between you and one or more suppliers. The panel's website can be up while a supplier's API is down. The catalogue can still show the row, because the row was copied before the failure. The order page can still accept the order, because the panel's own database is working. The delivery is the part that stops.

Ask which layer the status refers to. A page that says "all systems operational" without naming the layers is a page about the website. A page that separates catalogue, order placement, delivery and support is a page about the service. The second is more useful, and it is also more honest, because it can show a green website next to a red supplier.

If the panel does not publish a layered status, ask support a direct question: which supplier carries the row, and is that supplier's queue moving today? The answer is a status report for the layer that matters. A public log is evidence. A badge is a mood.

Your own log

When the panel does not publish a useful status page, keep your own. Five fields per order are enough: the order id, the time you paid, the time the order started, the time it completed or stopped, and the count at seven days. Add the support reply time if you asked a question. Over a month, the rows show a trend that a single check cannot.

The log also gives you a baseline for a switch. If a panel's start times stretch from hours to days, the log shows the change before a large order is exposed to it. If a partial delivery is settled without a ticket, the log shows the settlement time. Those are the signals a status page is supposed to provide, and you can collect them yourself.

How to read a queue depth

A queue depth is a number with a direction. A depth that is high but falling is a queue that is moving. A depth that is low but rising for several days is a queue that is filling faster than it drains. The direction matters more than the number, because the number depends on the size of the service and the time of day.

Ask for the depth twice, a day apart, if the order is large. The first number is a snapshot. The second number is a trend. A panel that can give both is a panel that can see the queue. A panel that gives a different number to the same question on the same day is a panel that is guessing, or one that is telling you what it thinks you want to hear.

The queue also has a timeout. A queue without a timeout is a place where an order can sit while the deadline passes. The timeout is the number that turns a wait into a decision: if the order has not started by then, it is refunded. Ask for it, and write it next to the order id.

When the page is stale

A stale status page is not a reason to panic, and it is not a reason to ignore the page. It is a reason to switch to the live signals: the order page, the catalogue count and a support question. The order page shows the state of your order. The catalogue count shows whether the panel is still reading its suppliers. The support answer shows whether a person can see the queue.

If the page is stale and the order page is moving, the service is working and the status page is not being updated. If the page is stale and the order page is stuck, the service may be down and the page is hiding it. The pair tells you which. A single green badge tells you neither.

Place a minimum order before a large one when the page is stale. The minimum order is an inexpensive way to test whether the live service matches the published status. If it starts and delivers, the stale page is a maintenance problem. If it does not, the page was the warning.

Red flags

• A status page with no timestamps. A colour without a time is a mood.
• A page that has never shown an incident. Every service has one. A history with no entries is a history that is not published.
• A maintenance notice with no date. "Scheduled maintenance" without a window cannot be planned around.
• An uptime percentage with no log. A number without a check behind it is marketing.
• A status page that is an image. An image cannot be timestamped, linked or updated by a monitor.
• A green page while the catalogue is stale. The website is up; the service is selling an old list.

A flag is not a verdict. A small operator can run a plain page and an honest process. The point is comparison: between two panels at a similar price, the one that publishes timestamps gives you more to check and less to take on faith.

A five-minute check before you deposit

1. Find the last sync timestamp. If there is none, treat the page as decoration.
2. Read the catalogue size. Compare it with the count you saw last week. A large drop needs an explanation.
3. Look for a failure count. Named and dated is evidence; a green dot is a mood.
4. Ask which layer is green. Website, catalogue, order placement, delivery, support. A page that names the layers is a page you can use.
5. Check the order page for the row you want. Start estimate, remains, last change. The order page is the live status of your order.
6. Write the five-field log entry. Order id, paid, started, finished, count at seven days.
7. Decide the stop rule. If the page cannot be read and support cannot name the layer, do not deposit a large balance.

The status page is a small window into a large process. Read it for the timestamp, the layer and the history. If those three are missing, the window is painted on, and your own log is the instrument you control.

For the public status page on this site, open the status page. For a quick check of a panel's public catalogue, use the panel check tool. For the questions that reveal how a panel operates, read the five questions.