{ "schema": 1, "generated_at": "2026-09-24T06:43:08.000Z", "window": { "days": 90, "from": "2026-06-27", "to": "2026-09-24", "basis": "overlap" }, "truncated": false, "limit": 50, "severities": { "outage": "A monitored surface did not serve customer requests.", "degraded": "It served, but slowly or intermittently.", "maintenance": "Planned work, at a time we chose.", "measurement": "The measurement was wrong and the platform was not. The samples are left exactly as recorded; this entry says why they should not be read as an outage. Where the entry also carries excludes_uptime, those minutes are counted as unmeasured rather than as downtime — never as uptime — and the affected rows report how many." }, "note": "Incidents are written by a person, after the fact. They annotate the measured record and they never rewrite it: probe_samples is append-only and no code path in this API edits or deletes a sample. One narrow adjustment is possible and it is always disclosed — an incident may be marked excludes_uptime, which counts the minutes inside its own window, for the components it names, as UNMEASURED rather than as up or down. Those minutes are never counted as up: an excluded minute is one we could not measure, not one we are claiming was fine. Every affected uptime object reports excluded_minutes, its split into excluded_up_minutes and excluded_down_minutes, and the ids in excluded_by; coverage falls by the excluded span. To recover the figure we would have shown without the exclusion: (up_minutes + excluded_up_minutes) / (measured_minutes + excluded_minutes) * 100.", "incidents": [ { "id": "2026-09-10-automated-traffic-surge-website-unavailable", "severity": "outage", "state": "resolved", "title": "Website intermittently unavailable during a surge of automated traffic", "started_at": "2026-09-10T00:00:00.000Z", "ended_at": "2026-09-12T04:29:26.000Z", "components": [ "api", "site" ], "days": [ "2026-09-10", "2026-09-11", "2026-09-12" ], "excludes_uptime": false, "body": "Between 10 and 12 September the website intermittently failed to load. The interruptions totalled 91 minutes across the three days and came in short episodes: most lasted under 15 seconds, and the longest was just under three minutes.\n\nTrading, settlement, balances and account data were unaffected throughout. The REST API was affected once, for about 90 seconds on 12 September. No orders were lost and no customer data was affected.\n\nThe cause was a sustained surge of automated third-party traffic concentrated on a narrow set of unusually expensive requests. It was heavy enough to exhaust capacity on the web tier, and while it did, real visitors were denied service. This was a denial-of-service condition produced by automated traffic; we have no indication that it was deliberate.\n\nWe identified the traffic and blocked it at 02:00 UTC on 12 September. The last interruption was at 04:29 UTC and there have been none since. We are adding request-rate limits at our network edge so that no single client can exhaust that capacity again, whatever its intent.", "duration_minutes": 3149, "component_labels": [ "REST API", "Website" ], "author": "platform", "updated_at": "2026-09-12T08:45:09.000Z", "updates": [] }, { "id": "2026-09-03-polymarket-market-data-feed-intermittent", "severity": "degraded", "state": "resolved", "title": "Polymarket market data feed intermittent", "started_at": "2026-09-03T21:05:00.000Z", "ended_at": "2026-09-03T21:39:00.000Z", "components": [], "days": [ "2026-09-03" ], "excludes_uptime": false, "body": "Polymarket reopened its incident a third time (status monitoring, impact major outage). Order-book updates on PolySimulator alternated between normal and several minutes stale; public trade data lagged. Prices and fills may have lagged intermittently; balances were unaffected. Polymarket resolved the incident at 21:39Z; our banner cleared automatically as feeds normalised.", "duration_minutes": 34, "component_labels": [], "author": null, "updated_at": "2026-09-03T21:39:50.000Z", "updates": [] }, { "id": "2026-09-03-polymarket-market-data-feed-degraded-relapse", "severity": "degraded", "state": "resolved", "title": "Polymarket market data feed degraded (relapse)", "started_at": "2026-09-03T20:05:00.000Z", "ended_at": "2026-09-03T20:28:00.000Z", "components": [], "days": [ "2026-09-03" ], "excludes_uptime": false, "body": "Polymarket's market data feed stalled again from about 20:05Z to 20:28Z, twenty minutes after its earlier incident was resolved: order-book updates stopped and public trade flow dropped to zero. Prices on PolySimulator were stale and fills delayed during the window; balances were unaffected. Order books have been updating normally since 20:28Z.", "duration_minutes": 23, "component_labels": [], "author": null, "updated_at": "2026-09-03T20:33:38.000Z", "updates": [] }, { "id": "2026-09-03-polymarket-market-data-feed-degraded", "severity": "degraded", "state": "resolved", "title": "Polymarket market data feed degraded (upstream)", "started_at": "2026-09-03T17:15:00.000Z", "ended_at": "2026-09-03T19:45:00.000Z", "components": [], "days": [ "2026-09-03" ], "excludes_uptime": false, "body": "Polymarket's trading API and market data feeds were degraded; fills and live prices on PolySimulator were affected for most of the window. Balances were unaffected. 17:06Z: Polymarket acknowledged delayed open-order reads. 19:15Z: fix under monitoring. 19:45Z: Polymarket resolved the incident; our automatic banner cleared once order books were updating normally again.", "duration_minutes": 150, "component_labels": [], "author": null, "updated_at": "2026-09-03T19:46:19.000Z", "updates": [] }, { "id": "2026-09-03-polymarket-multi-component-incident", "severity": "degraded", "state": "resolved", "title": "Polymarket market data and trading incident (upstream)", "started_at": "2026-09-03T13:07:00.000Z", "ended_at": "2026-09-03T13:26:00.000Z", "components": [], "days": [ "2026-09-03" ], "excludes_uptime": false, "body": "Polymarket reported a 19-minute incident affecting its trading API, websockets and market data. Order books on PolySimulator did not move during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 19, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:35.000Z", "updates": [] }, { "id": "2026-09-03-polymarket-cancel-issues", "severity": "degraded", "state": "resolved", "title": "Polymarket order cancellation issues (upstream)", "started_at": "2026-09-03T11:41:00.000Z", "ended_at": "2026-09-03T12:10:00.000Z", "components": [], "days": [ "2026-09-03" ], "excludes_uptime": false, "body": "Polymarket reported problems cancelling orders for 29 minutes. Cancellations on PolySimulator were unaffected; venue order books were briefly stale. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 29, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:34.000Z", "updates": [] }, { "id": "2026-09-03-deployment-liveness-blips", "severity": "maintenance", "state": "resolved", "title": "Brief liveness errors during rolling deployments", "started_at": "2026-09-03T09:00:00.000Z", "ended_at": "2026-09-03T15:00:00.000Z", "components": [ "api" ], "days": [ "2026-09-03" ], "excludes_uptime": false, "body": "On 3 September, six rolling deployments between about 09:00 and 15:00 UTC each caused 10 to 60 seconds of failing liveness checks on the API. User requests kept being served throughout; the failing signal was the deployment drain marker, which the status probe also reads. A change that separates the deployment signal from the public liveness endpoint ships in the next release.", "duration_minutes": 360, "component_labels": [ "REST API" ], "author": null, "updated_at": "2026-09-03T18:00:32.000Z", "updates": [] }, { "id": "2026-09-02-post-deployment-cold-start", "severity": "degraded", "state": "resolved", "title": "API degraded for about 8 minutes after a deployment", "started_at": "2026-09-02T21:08:00.000Z", "ended_at": "2026-09-02T21:16:00.000Z", "components": [ "api" ], "days": [ "2026-09-02" ], "excludes_uptime": false, "body": "Between 21:08 and 21:16 UTC on 2 September, API requests were slow after a deployment while connections re-established. Mitigated the same evening with connection-pool changes; later deployments were verified with an external probe. Balances and positions were unaffected.", "duration_minutes": 8, "component_labels": [ "REST API" ], "author": null, "updated_at": "2026-09-03T18:00:32.000Z", "updates": [] }, { "id": "2026-09-02-api-connection-pool-exhaustion", "severity": "degraded", "state": "resolved", "title": "API slow or failing for about 8 minutes", "started_at": "2026-09-02T13:54:00.000Z", "ended_at": "2026-09-02T14:02:00.000Z", "components": [ "api", "api_authed" ], "days": [ "2026-09-02" ], "excludes_uptime": false, "body": "Between 13:54 and 14:02 UTC on 2 September, API requests were slow and some failed. Cause: the database connection pool was exhausted under load. Fixed the same day by resizing the pool. Balances, positions and order history were unaffected.", "duration_minutes": 8, "component_labels": [ "REST API", "Authenticated API" ], "author": null, "updated_at": "2026-09-03T18:00:31.000Z", "updates": [] }, { "id": "2026-09-02-market-list-slowness", "severity": "degraded", "state": "resolved", "title": "Market lists and search intermittently slow", "started_at": "2026-09-02T12:00:00.000Z", "ended_at": "2026-09-02T15:45:00.000Z", "components": [ "api", "site" ], "days": [ "2026-09-02" ], "excludes_uptime": false, "body": "During the afternoon of 2 September (roughly 12:00 to 15:45 UTC), market lists and search were intermittently slow. Cause: a cache refresh storm with three contributing sources, all fixed and deployed the same day. Trading, balances and positions were unaffected.", "duration_minutes": 225, "component_labels": [ "REST API", "Website" ], "author": null, "updated_at": "2026-09-03T18:00:31.000Z", "updates": [] }, { "id": "2026-09-01-polymarket-trading-paused-overnight", "severity": "degraded", "state": "resolved", "title": "Polymarket trading paused overnight (upstream)", "started_at": "2026-09-01T20:21:00.000Z", "ended_at": "2026-09-02T04:58:00.000Z", "components": [], "days": [ "2026-09-01", "2026-09-02" ], "excludes_uptime": false, "body": "Polymarket paused trading for about 8.5 hours for a database clean-up and an emergency CLOB maintenance. Order books on PolySimulator did not move and fills were delayed during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 517, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:34.000Z", "updates": [] }, { "id": "2026-08-31-polymarket-trading-paused-evening", "severity": "degraded", "state": "resolved", "title": "Polymarket trading degraded for 4.5 hours (upstream)", "started_at": "2026-08-31T20:28:00.000Z", "ended_at": "2026-09-01T01:07:00.000Z", "components": [], "days": [ "2026-08-31", "2026-09-01" ], "excludes_uptime": false, "body": "Polymarket reported delayed order reads and paused trading for parts of a 4 hour 39 minute window. Order books on PolySimulator did not move and fills were delayed during the affected parts. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 279, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:34.000Z", "updates": [] }, { "id": "2026-08-31-polymarket-trading-paused-morning", "severity": "degraded", "state": "resolved", "title": "Polymarket trading paused for 4.5 hours (upstream)", "started_at": "2026-08-31T06:23:00.000Z", "ended_at": "2026-08-31T10:48:00.000Z", "components": [], "days": [ "2026-08-31" ], "excludes_uptime": false, "body": "Polymarket paused trading for about 4 hours 25 minutes while investigating delayed order reads. Order books on PolySimulator did not move and fills were delayed during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 265, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:34.000Z", "updates": [] }, { "id": "2026-08-31-polymarket-cancel-only", "severity": "degraded", "state": "resolved", "title": "Polymarket cancel-only mode (upstream)", "started_at": "2026-08-31T00:40:00.000Z", "ended_at": "2026-08-31T01:12:00.000Z", "components": [], "days": [ "2026-08-31" ], "excludes_uptime": false, "body": "Polymarket ran in cancel-only mode for 32 minutes. Order books on PolySimulator did not move and fills were delayed during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 32, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:33.000Z", "updates": [] }, { "id": "2026-08-30-polymarket-trading-paused", "severity": "degraded", "state": "resolved", "title": "Polymarket trading paused (upstream)", "started_at": "2026-08-30T17:36:00.000Z", "ended_at": "2026-08-30T18:28:00.000Z", "components": [], "days": [ "2026-08-30" ], "excludes_uptime": false, "body": "Polymarket paused trading for 52 minutes while investigating delayed order reads. Order books on PolySimulator did not move and fills were delayed during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 52, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:33.000Z", "updates": [] }, { "id": "2026-08-26-polymarket-clob-maintenance", "severity": "maintenance", "state": "resolved", "title": "Polymarket CLOB maintenance (upstream)", "started_at": "2026-08-26T04:00:00.000Z", "ended_at": "2026-08-26T07:30:00.000Z", "components": [], "days": [ "2026-08-26" ], "excludes_uptime": false, "body": "Polymarket's scheduled CLOB maintenance ran about 3.5 hours; our capture of their trade tape shows activity stopped until about 08:20 UTC. Order books on PolySimulator did not move during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 210, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:33.000Z", "updates": [] }, { "id": "2026-08-22-polymarket-trading-paused", "severity": "degraded", "state": "resolved", "title": "Polymarket trading paused (upstream)", "started_at": "2026-08-22T13:13:00.000Z", "ended_at": "2026-08-22T13:51:00.000Z", "components": [], "days": [ "2026-08-22" ], "excludes_uptime": false, "body": "Polymarket paused trading for 38 minutes due to an issue on their side. On PolySimulator, order books did not move and fills were delayed during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 38, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:33.000Z", "updates": [] }, { "id": "2026-08-19-polymarket-trading-outage", "severity": "degraded", "state": "resolved", "title": "Polymarket trading outage (upstream)", "started_at": "2026-08-19T09:19:00.000Z", "ended_at": "2026-08-19T10:58:00.000Z", "components": [], "days": [ "2026-08-19" ], "excludes_uptime": false, "body": "Polymarket reported a trading outage with order submission failures for about 1 hour 40 minutes. On PolySimulator, order books did not move and fills were delayed during the window. Upstream: Polymarket incident, not a fault on PolySimulator. Balances, positions and order history were unaffected; our own probes were up throughout, so this is not subtracted from the uptime figures above.", "duration_minutes": 99, "component_labels": [], "author": null, "updated_at": "2026-09-03T18:00:32.000Z", "updates": [] }, { "id": "2026-08-14-updown-trading-and-catalog-degradation", "severity": "degraded", "state": "resolved", "title": "Up/Down trading and market catalogue degraded", "started_at": "2026-08-14T08:00:00.000Z", "ended_at": "2026-08-14T19:00:00.000Z", "components": [ "api", "site", "websocket" ], "days": [ "2026-08-14" ], "excludes_uptime": false, "body": "Through the day on 14 August, short-horizon (Up/Down) trading and parts of the market catalogue were intermittently degraded. Market orders could fill against quotes that were tens of seconds old instead of live ones, some price charts failed to load during routine service restarts, and event pages could show only a subset of their outcomes - an internal listing limit meant an event with dozens of outcomes could render only a few.\n\nA deploy at 12:47 UTC also failed one of its own safety checks and the API was fully down for three minutes (12:47-12:50). Separately, between 16:01 and 17:15 the first fix for the catalogue issue put more load on a cache than it had room for, which degraded response times until it was corrected.\n\nWhat changed, all deployed the same day: order fills now enforce freshness bounds on every price source, so a trade re-prices from live data instead of silently using a stale quote; event pages serve their complete outcome lists from the full live market catalogue; the caching layer was given substantially more capacity on the larger server the platform moved to after the 12-13 August incidents; and WebSocket connections now close cleanly during routine restarts instead of dropping mid-stream. The platform has been stable since.", "duration_minutes": 660, "component_labels": [ "REST API", "Website", "WebSocket streams" ], "author": "platform", "updated_at": "2026-08-14T20:25:12.000Z", "updates": [] }, { "id": "2026-08-13-write-path-degradation", "severity": "degraded", "state": "resolved", "title": "Order placement and cancellation degraded for 11 minutes", "started_at": "2026-08-13T12:52:00.000Z", "ended_at": "2026-08-13T13:03:00.000Z", "components": [], "days": [ "2026-08-13" ], "excludes_uptime": false, "body": "Between 12:52 and 13:03 UTC on 13 August, order placement and cancellation failed for about 11 minutes. Reads were unaffected throughout: market data, prices, portfolios, order history and the website all served normally, and open positions were never at risk.\n\nCause. An internal tooling error during a maintenance audit interfered with the write path. It was ours, it was not a defect in the platform's own code, and it was reverted as soon as it was identified. Full write service was restored at 13:03 UTC.\n\nWhy this does not appear in the bars above. Every probe behind the figures on this page exercises a read path: it fetches the homepage, calls a public API endpoint, calls an authenticated API endpoint, and opens a WebSocket. None of them place an order. A write-only fault is therefore invisible to this page's measurements by construction, and the 13 August figures do not include these 11 minutes. It is recorded here because this page failing to see something is not the same as it not having happened, and an omission a reader cannot detect is the one kind this record cannot carry. A write-path probe is planned so the next one is measured rather than only described.\n\nThis entry names no component row for the same reason: none of the four rows above measures the write path, and attaching it to one would put a mark under a figure that did not move.", "duration_minutes": 11, "component_labels": [], "author": "platform", "updated_at": "2026-08-13T13:45:00.000Z", "updates": [] }, { "id": "2026-08-12-release-memory-defects", "severity": "outage", "state": "resolved", "title": "Elevated error rates and brief interruptions following the Aug 12 release", "started_at": "2026-08-12T17:45:00.000Z", "ended_at": "2026-08-13T11:00:00.000Z", "components": [ "api", "api_authed", "site", "websocket" ], "days": [ "2026-08-12", "2026-08-13" ], "excludes_uptime": false, "body": "Between 17:45 UTC on 12 August and 11:00 UTC on 13 August the platform ran with two memory defects in its own code. Requests failed in short bursts while we found and fixed them. Trading was continuous throughout and no data was lost.\n\nWhat happened. A release on 12 August introduced memory defects in two backend services. Both ended the same way: an affected process grew until it was reclaimed and stopped answering for the seconds to few minutes it took to come back. Supervision restarted the services automatically each time, which is why this window is a scatter of short interruptions rather than one continuous outage.\n\nWhat it cost, in this page's own numbers. The 12 August cells are final and read: Website 1 minute not responding and 41 minutes slow; REST API 5 minutes not responding and 16 slow; Authenticated API 3 minutes not responding and 12 slow; WebSocket streams 10 minutes not responding and 6 slow. 13 August carried a further few minutes on the API and WebSocket rows before the fixes landed. A day cell counts a whole UTC day, so those totals also cover hours outside this incident's window - they bound what it cost rather than isolate it. Each individual interruption was seconds to a couple of minutes; the totals are the sum of several.\n\nPlanned work inside the same window. One interruption of roughly 100 seconds during the night was ours and deliberate: we moved the platform onto a larger server with substantially more headroom. That is not the fix for the defects above and we are not presenting it as one; it raises the margin a fault has to eat through before customers feel it.\n\nWhere it stands. Permanent fixes for both defects were deployed on the morning of 13 August, and this entry was closed at 11:00 UTC after the platform had stayed stable. No data was lost: positions, balances and order history are unaffected, and requests that failed during a restart failed cleanly rather than half-completing. Nothing in this window is excluded from the figures above. The failures were ours and they were real, so they stay in the arithmetic.", "duration_minutes": 1035, "component_labels": [ "REST API", "Authenticated API", "Website", "WebSocket streams" ], "author": "platform", "updated_at": "2026-08-14T20:25:12.000Z", "updates": [] }, { "id": "2026-08-10-prober-false-outage", "severity": "measurement", "state": "resolved", "title": "Status page reported an outage that did not happen", "started_at": "2026-08-10T16:04:00.000Z", "ended_at": "2026-08-10T17:52:00.000Z", "components": [ "site", "websocket" ], "days": [ "2026-08-10" ], "excludes_uptime": true, "body": "Between 16:04 and 17:51 UTC this page reported the Website and WebSocket streams as not responding. Both were serving normally the whole time. Our internal metrics, our CDN logs and the two API checks on this page all agree on that. The fault was in our measurement, not in the platform.\n\nTwo defects in our own prober caused it. Our edge protection started challenging the prober, which a non-browser client cannot answer. Separately, the homepage check downloaded the entire page to look for a marker near the top, and from a distant location that ran past its deadline. Both are now fixed, and a second independent measuring location runs alongside the first, so a single vantage can no longer report an outage on its own.\n\nThe affected minutes are excluded from the figures above and shown as unmeasured rather than as uptime. The prober took no valid reading in that window, so we will not record one. The raw samples are unchanged and the excluded count is published next to each figure. One window covers both components, which discards about 19 minutes of valid WebSocket measurement rather than claim a tighter boundary than we can evidence.", "duration_minutes": 108, "component_labels": [ "Website", "WebSocket streams" ], "author": "platform", "updated_at": "2026-08-11T13:04:02.000Z", "updates": [] } ] }