Witnesses

Most hours of this archive are recorded by several machines at once, and the audit lists the actual number of witnesses for each hour. We call the machines witnesses. The merge keeps everything any of them heard, so a bad hour on one machine does not become a hole in the archive. This page is about the machines themselves: where they are, how much of each hour they catch, and how quickly they hear it.

Last seven days: 2026-10-13T00 to 2026-10-19T23, 168 hours. Computed 2026-10-20T01:41:43Z from the merge's own accounting; the file is served as witness-stats-7d.json.

The witnesses

Five machines have shipped rows in the last seven days, all live. "Good hours" are hours where the machine caught at least 90% of everything the fleet heard: if every other machine had failed, the merge would still hold at least nine rows in ten. "Missed" are hours it should have shipped and did not. Book snapshots are left out of these shares: a machine is sent them again after each of its own reconnects, so they are copies, not rows another machine missed.

How often was each witness good

For every hour a machine was meant to be recording, from the first hour it shipped to the newest, the bars show what fraction of those hours landed in each band. A missed hour counts as zero. Hours before a machine went live are not counted against it, and after g came back from an outage on 2026-09-23 the hours before its return are not counted against it either. Every chart uses the same scale, so a machine that joined yesterday can be read against one that has run all week; the counts say how much history each one has. Hatched parts of a bar are hours inside a Polymarket incident, so a bad hour with a known cause looks different from one without.

good, 90% and up50 to 90%below 50%inside a venue incident

What happened on the venue this week

Some bad hours are ours and some are Polymarket's. The top row marks hours that fall inside an incident on Polymarket's own status page. The bottom row marks hours where the merged archive holds less than half the usual volume, whatever the reason. When the two line up, the venue was quiet and there was less to hear.

No incident in our register falls inside this window.

What each extra witness adds

Events only: book snapshots are left out, because one witness replays subscription snapshots whose exchange timestamps are minutes to days old, and those are not new events. For every hour, the witnesses present are the ones that shipped rows. The best one alone caught the largest share of the merged event rows; everything the others added on top is the rest. Rows only one witness had are the ones the merge would have lost if that machine alone had failed.

The merge began counting these on 2026-09-06; figures land here when the exporter carries them. Hours before that field existed cannot be reconstructed.

Why a low contribution is not a bad witness. The rows from different witnesses are the same events. The merge keeps one copy of each, and which copy the merge kept is a per-hour fact, read from the hour's merger stamp: fcbb2804 and later keep the earliest-received copy; earlier stamps keep the copy from the machine most recently added to the fleet. So a "won" figure says who was the newest machine in the fleet on hours under the older rule, and who was fastest on hours under the newer one; it says nothing about quality either way. The figures on this page measure what each witness heard, which is the fair question.

Rows each machine delivered, by how busy the hour was

One panel per machine and one dot per hour. Across is the rows the merged archive holds for that hour, from every machine together; up is the rows this machine delivered of them. The dashed line is where nothing was missed. Book snapshots are left out of both counts: a machine is sent them again after each of its own reconnects, so they are copies, not rows another machine missed.

on this line, nothing was missedone hourbelow the chart, drawn on its bottom edge

A dot on the dashed line is an hour this machine missed nothing; how far a dot sits under the line is what it missed. Every panel uses the same scale, so the busiest hours sit furthest right on all of them. A machine that keeps up at any volume stays on the line from end to end. A machine with a ceiling follows the line through quiet hours, then bends away from it and goes flat: the height where it flattens is the most it can record in an hour. One thing this cannot show: the merged count is everything any machine heard, so if every machine missed the same rows, the merged count is short too and the dots still sit on the line. The coverage audit is where that shows.

The same in numbers: rows missed per hour, typical and worst, with the hours behind them, for each quarter of the window's hours by merged volume.

Latency, the week in one histogram per witness

How long after an event happened did each machine receive it? The bars show the whole week's rows across sixteen fixed buckets, from a clock that ran backwards, through under a millisecond, to over thirty seconds. Every chart uses the same scale. The p50 and p90 marks are upper bounds: the buckets have fixed edges, so we can say the median is at most 50 ms, not that it is exactly 50 ms.

How to read these numbers

• Share is measured against the merged archive, which is the union of every machine's rows. It says how much of what the fleet heard this machine also heard. It does not say what the fleet missed; the coverage audit answers that.
• The seven-day window rolls forward every hour. The figures on this page are recomputed from the merge's own accounting each time it runs, and the time they were last computed is printed at the top.
• Locations are declared by us, not measured. We publish the city or country and never the hosting company, because naming the host tells someone where to aim and tells you nothing about the data.
• A witness that is held in reserve or retired keeps its record. Retirement is an end date on its record, never a deletion. It leaves this page once it has no shipped hour inside the window.

Reconnects are normal and cannot be avoided

Polymarket's live feed arrives over WebSocket connections, and one connection can follow only a limited number of markets, so each machine holds about 1,900 connections at once. Connections end for ordinary reasons: Polymarket restarts its own servers and closes every connection on them, a quiet connection is closed, or the network path between the machine and Polymarket drops. The machine re-opens the connection, usually within a second, and Polymarket sends a fresh copy of the book for every market on it, so the book is right again from that moment. What that one machine misses is the changes during the gap. That is why several machines in different places record at once: a gap on one is filled by the others, and a change is lost only if every machine was reconnecting on that market at the same instant.

How much each machine missed is shown by its share of rows in the tables above, not by a count of reconnects: a machine's own count cannot see a restart of its recording program, which takes every connection down at once.