All Systems Operational

Outbound email is sending.

Checked 3 min ago. The transport answered a reachability probe. Last successful send 16 Sep 02:20 UTC (47 min ago).

• Transport: gmail_outbox — reachable (HTTP 200 in 300ms)
• Last successful send: 16 Sep 02:20 UTC (47 min ago)
• Consecutive failures: 0 — an outage is declared at 3
• Check last ran: 16 Sep 03:04 UTC (3 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.

Gaps in monitoring

Uptime above is computed over the checks that actually ran. When the monitor itself is not running, that time is neither up nor down — it is unknown, and dividing it out would quietly inflate every percentage. Every such gap is listed here.

25 Jun 02:30 UTC → 29 Jun 23:13 UTC — 116.7 hours with no checks recorded.

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 — but note what it targets: it probes the website, not api.puntersedge.online. The /v1/uptime endpoint is backed by this same file, so read its number as website availability measured from the API box.

99.97% over the last 30 days (8639 checks, monitor running for 100.0% of the window). Buffer holds the most recent 8640 checks, spanning 30.0 days from 17 Aug 2026; last check 16 Sep 03:04 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.

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.

Data freshness

This page is about service availability. It says nothing about how fresh the odds inside a response are — that is a separate, separately measured thing, 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; stale_after_seconds is 1800, twice the nominal 900-second poll, so a market flips to stale only after two polls have failed to refresh it. 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 check pages the operator on the first failure and again on recovery.
• 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.