This is a sports & gaming problem we approach through our 24×7 Operations Desk service line.
The problem
Racing load is not evenly distributed and never has been. It arrives in the last two minutes before each jump, repeatedly, across overlapping meetings, and the heaviest days are Saturdays and public holidays — exactly when the people who wrote the platform are least available.
Most operators cover this with an on-call rotation and a monitoring dashboard. That arrangement handles outages. It handles badly the thing that actually costs money: a component that is up, healthy and quietly wrong. A price feed that stopped updating. A market that should have suspended and did not. A settlement queue that stalled behind one bad result.
By the time a customer complaint reaches the on-call engineer, the race has run.
Why it’s hard
The failure that matters is not an outage. Availability monitoring answers whether the service responds. Race day requires knowing whether the data is current, whether markets are in the state they should be in for where the meeting is up to, and whether bets are being accepted into something that should have closed. Those are correctness questions, and a liveness probe cannot express them.
A stopped feed looks perfectly healthy. The process is running, the connection is open, the last message parsed. Detecting it requires a staleness threshold per feed and per market state, and the threshold that is right at 2pm on a Saturday is wrong at 2am on a Tuesday.
Peak shape is predictable, peak magnitude is not. You know load concentrates before each jump. You do not know that a particular Saturday will carry a Group 1, a late scratching in a feature race and an unrelated sports fixture at the same time. Autoscaling that reacts after the fact reacts too late for a two-minute peak, so capacity has to be anticipated against the meeting schedule rather than the CPU graph.
Post-race work has its own failure profile. Protests, amended results, late dividend declarations and refund cascades all arrive after the excitement, and they are the ones that create financial discrepancies rather than customer complaints. A settlement backlog is quieter than an outage and more expensive to unwind.
Deploys cannot happen when the platform is busy, which is when people want to fix things. A change freeze across racing hours is straightforward to agree and hard to hold, and every exception needs a decision path that does not run through a group chat.
Australian time zones are an operational trap. Queensland and Western Australia do not observe daylight saving, so for several months of the year the offset between states changes and offsets that were hard-coded somewhere start scheduling things wrongly. Meeting times, market open windows, cut-off calculations and reporting periods all inherit that. This is a routine source of real incidents, not a footnote.
An alert without a runbook is a page to somebody who then reads code. The difference between a desk that resolves and a desk that relays is entirely whether the runbook was written by someone who understood the failure.
How we approach it
Monitoring built by the people who built the platform. On our own wagering platform, Prometheus and Grafana are instrumented alongside custom notifier scripts, and the alert set was written against the failure modes the engineering team already knew about. Instrumentation retrofitted by an operations vendor who has never read the code measures what is easy to measure.
Staleness and rate-of-change alerting, not just up and down. Alerts fire on data that has stopped moving, on values moving faster than they should, and on market state that disagrees with meeting state. These catch the silent failures that availability monitoring passes.
Proactive notification, ahead of the customer. Alerting is configured to notify before impact where a leading indicator exists — queue depth rising, processing latency drifting, a feed slowing before it stops — which is the difference between reducing incident duration and reducing incident count.
Thresholds that know what day it is. Alert thresholds are conditioned on the racing calendar rather than fixed. A quiet Tuesday and a Saturday metro card do not share a normal.
A runbook per alert, and escalation to the code owners. Every alert has a documented response and a defined boundary: what the desk resolves, what it escalates, and to whom. Escalation goes to engineers who own the platform, not to a second-line queue that will read the same dashboard.
A change freeze the desk enforces on itself. Deployments are Helm-driven and scheduled outside racing hours, and the freeze applies to our releases as much as the operator’s. Exceptions require a named person’s decision.
Coverage aligned to Australian racing and business hours. We have no Australian entity or office and we do not imply one. What we do is cover the hours that matter for Australian racing, which is the requirement rather than the postcode.
What we would not do. We would not take on cover for a platform with no runbooks and no instrumentation and call it a managed service — the first engagement in that situation is building the observability, and we will scope it as that. We would not accept authority to suspend markets without it being written down. And we would not run a desk that cannot escalate into the code, because a desk that can only restart things is a delay mechanism.
What it takes
Access, properly provisioned. Monitoring, logs, dashboards, deployment pipeline and the systems the runbooks touch, with per-person accounts and an audit trail. This is usually the longest lead item.
Runbooks, or budget to write them. If they do not exist, that is the first deliverable. Cover without runbooks is availability theatre.
An escalation contract. Who we call, in what order, at 3am, and what we are authorised to do before we reach them.
A decision on the desk’s unilateral authority. Restart a service, yes. Scale a component, usually. Suspend a market, only if written down. This split needs the operator’s trading and compliance functions, not just engineering.
The racing calendar as data. Meeting schedules and feature days, so thresholds and capacity planning can be conditioned on them rather than guessed.
Where this has been done
This is a shipped reference under confidentiality. We built and continue to operate a multi-tenant tote and fixed-odds betting platform in production. It runs on Kubernetes with auto-scaling and fault-tolerant services, and it is instrumented with Prometheus, Grafana and custom notifier scripts for self-monitoring, with alerting configured for proactive error notification rather than post-incident discovery. Tenant deployment is Helm-driven.
No availability or uptime figures appear on this page because none have been cleared for publication — if uptime is a procurement criterion for you, ask us directly and we will answer in a conversation where the number can be qualified.
The desk pattern is not specific to racing. Any platform with a concentrated, scheduled peak and correctness requirements that outrun availability monitoring has the same operational shape.