API operational · data degraded

What each measurement covers

Primary indicator, the customer path: 99.59% of external, authenticated runs passed since 13 Oct 2026 — 5391 runs over 18.7 days, with the probe running for 100.0% of that period. A run passes only when the edge check and an authenticated request both pass.

The per-measure record starts 18 Oct 2026; earlier external runs kept one pass or fail per run, which is the run-level figure above. None of these is a contractual SLA, and passing all six does not prove every endpoint answers correctly — each row says what it checks.

Every dataset checked for the headline (17)

• OK GB greyhound full fields · Every collectable race in the window is complete or still inside its settle time (867 races). (measured 1 Nov 2026 00:24 UTC)
• OK US harness full fields · Every collectable race in the window is complete or still inside its settle time (549 races). (measured 1 Nov 2026 00:24 UTC)
• Partial AU greyhound full fields, tracks outside Victoria · 5 of 496 races are overdue, under the 25% share at which this page calls the dataset degraded. (measured 1 Nov 2026 00:24 UTC)
• OK US thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (486 races). (measured 1 Nov 2026 00:24 UTC)
• OK AU thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (285 races). (measured 1 Nov 2026 00:24 UTC)
• OK AU greyhound full fields, Victorian tracks from 14 October 2026, and races the national pages left empty · Every collectable race in the window is complete or still inside its settle time (271 races). (measured 1 Nov 2026 00:24 UTC)
• OK AU harness full fields · Every collectable race in the window is complete or still inside its settle time (252 races). (measured 1 Nov 2026 00:24 UTC)
• OK GB thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (198 races). (measured 1 Nov 2026 00:24 UTC)
• OK CA harness full fields · Every collectable race in the window is complete or still inside its settle time (140 races). (measured 1 Nov 2026 00:24 UTC)
• OK IE greyhound full fields · Every collectable race in the window is complete or still inside its settle time (112 races). (measured 1 Nov 2026 00:24 UTC)
• OK IE thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (55 races). (measured 1 Nov 2026 00:24 UTC)
• OK ZA thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (52 races). (measured 1 Nov 2026 00:24 UTC)
• OK NZ thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (38 races). (measured 1 Nov 2026 00:24 UTC)
• OK NZ harness full fields · Every collectable race in the window is complete or still inside its settle time (34 races). (measured 1 Nov 2026 00:24 UTC)
• OK CA thoroughbred full fields · Every collectable race in the window is complete or still inside its settle time (30 races). (measured 1 Nov 2026 00:24 UTC)
• Degraded AU racing prices, bookmaker feeds · Bookmaker feeds with no recent price while races are running: BoostBet (no price for 119.3 h); BetGold (no price for 119.3 h). (measured 1 Nov 2026 00:25 UTC)
• OK AU racing prices, freshness on a customer request · The latest racing-day run found a race with fresh prices. (measured 1 Nov 2026 00:25 UTC)

A dataset is degraded when at least a quarter of its collectable races are overdue, when its source refuses our collector and placings or dividends are missing too, when a served bookmaker has gone dark, or when two consecutive racing-day external runs find no fresh prices. A refusing full-field source with placings and dividends intact is a scoped limitation, named with its tracks in its own notice. Partial, limited and not-assessed rows do not change the headline; a row whose measurement is older than its cadence is not current, never OK. Also in /status.json under datasets.

Outbound email is sending.

Checked 2 min ago. The transport answered a reachability probe. Last successful send 1 Nov 00:09 UTC (18 min ago).

• Transport: Resend, with the Gmail queue as fallback — reachable (send-only key recognised by Resend (314ms))
• Last successful send: 1 Nov 00:09 UTC (18 min ago)
• Consecutive failures: 0 — an outage is declared at 3
• Check last ran: 1 Nov 00:24 UTC (2 min ago) — counted as stale after 30 min

Measured by a separate monitor that reads the delivery result of every message the API sends and probes whether the configured transport is reachable — it never sends a test message to anyone. This page only reads what that monitor last wrote, which is why the time of its last run is published above: if the monitor stops, that timestamp stops moving, and no figure here can quietly go on looking healthy. Recipient addresses are masked and no message subject is published. Also available as JSON at /status.json.

Latency, yesterday (UTC) · errors per path

2026-10-31 · external callers, successful responses, measured at the application (excludes edge time). The roll-up covers 23 of that day's 24 hours, so these figures are partial.

On a narrow screen, swipe the table sideways for p99, 5xx and 4xx.

The hourly roll-up keeps percentiles, not raw timings, so the day's figures are combined from the hourly ones with each hour's requests counted at the top of their percentile band. They lean high rather than low. Requests and latency count successful responses only; the six busiest paths by that count, plus any other path that returned a server error. Errors are counted over every response the same external callers got on that path that day, from the same hourly roll-up. 5xx is a server error. 4xx is a client error: 402 is out of credits, 429 is rate limited, and the roll-up keeps 401, 403, 404 and other 4xx together as one class. Client errors include customers' own mistakes and exhausted credits, so they are not a measure of our availability; server errors are. Also in /status.json under latency.

Second, independent probe

A separate process on the API host polls https://puntersedge.online/ping on its own schedule. It is a useful cross-check because it shares no scheduler and no code path with the monitor above. Note what it reaches: the public host's nginx routes /ping to the API process, so this probe exercises DNS, TLS, nginx routing and the API process itself — but it carries no key and makes no database or data assertion. A pass means the API process answers, not that prices are flowing. The /v1/uptime endpoint is backed by this same file.

100.00% over the last 30 days (8640 checks, monitor running for 100.0% of the window). Buffer holds the most recent 8640 checks, spanning 30.0 days from 2 Oct 2026; last check 1 Nov 00:24 UTC.

How we measure — and what we do not promise

The checks

A process on the same DigitalOcean droplet as the services issues one HTTP request per surface and records the response code and whether it matched the expected code. The measured interval between checks over the last 24 hours is 10 minutes — measured from the history file rather than read off the scheduler, because the two have disagreed before. Each service card shows the exact URL probed and the code it expects.

The exception is API — external, authenticated: it runs on a machine outside the production host, presents a dedicated monitoring key, and checks what a customer's request gets back. Its card is grey whenever no result newer than 30 minutes exists — a missing check is never shown as a passing one.

2 of the 7 probes are loopback requests on the box itself. They confirm the application process is answering; they cannot detect a DNS, TLS, nginx or network failure that would take the service down for every customer. They are labelled Internal probe above and you should read them as narrower evidence than the external ones.

The percentages

• Uptime for a window = checks that returned the expected code / checks that ran in that window.
• A window longer than a service's recorded history is not shown at all. It is never rounded up to 100%.
• Each figure's tooltip carries the number of checks behind it and the share of the window in which the monitor was running. Anything under 100% coverage means part of that window is unknown.
• Each service's daily bars start at that service's first recorded check and run to today, up to a maximum of 90 days. They are not padded out to a fixed window: a surface with two days of record gets a two-day chart, labelled as such, rather than a 90-day axis over 88 blank days. Grey inside the range means no monitoring data for that day, not a good day.

Service availability and data quality

The headline answers two questions separately. Service availability is whether the site, the API and outbound email answer, from the checks on this page. Data quality is whether each dataset those answers carry is complete and current: race results with full fields per code, the bookmaker feeds, and fresh prices on a customer request. A degraded dataset is named in its own notice, with the date it began, what still works and what is missing, and it never marks the whole service degraded. A source we do not control that refuses one part of a dataset while the rest is intact, such as a full-field source while placings and dividends still arrive, is a scoped limitation: it gets its own notice listing the tracks, and the headline stays operational. A check whose last measurement is older than its expected cadence is shown as not current, never as healthy.

Data freshness

How fresh the odds inside a response are is published with its own p50/p90/max figures on the coverage page under “Data refresh rates”. Those numbers live in one place so they cannot drift apart; they are not restated here.

Every quote the API returns carries its own age. On sports responses the quality object gives score, status, age_seconds and stale_after_seconds, and a market flips to stale once its age_seconds passes that threshold, currently 30 minutes. Racing quotes carry a per-book age_seconds, and each race carries data_age_seconds — deliberately the age of the worst contributing book, not the best — alongside freshest_age_seconds. Read those rather than assuming a fixed panel of bookmakers is always quoting: overnight, when the Australian card has finished, far fewer books are.

What happens during an outage

• A failing public check is logged; a self-heal job on the host restarts the affected service within ten minutes. Collection and mail alarms page the operator separately.
• If an upstream bookmaker feed stops, the API keeps serving the last values it has and the age fields grow. It does not fabricate a price and it does not silently drop a book from the panel — the book's quote simply gets older, which is why the age fields are on every quote.
• If the monitor itself stops running, this page says so at the top rather than continuing to present the last known state as current, and the unobserved time is deducted from the coverage figures instead of being divided out.
• Customer-visible changes are recorded, dated, on the changelog, which also publishes JSON Feed and RSS.

What is not guaranteed

There is no contractual uptime SLA. Everything on this page is observed measurement of what has happened, published so you can judge it yourself. It is not a commitment about what will happen, there is no credit or refund schedule attached to it, and nothing here should be read as one. If you need a contractual availability commitment, ask — it is a conversation, not a published number.

This is not real-time tick data, and it is not suitable for latency-sensitive trading. Refresh rates depend on upstream bookmaker availability and rate limits.

Machine-readable

/uptime.json — availability per surface, each figure with its window, check count and coverage. /status.json — current up/down per service. Both carry the same caveats as fields, so a consumer that never reads this page still gets them.