What you can rely on, and what happens when something breaks
A golf platform is judged on the Saturday morning when the sheet has to work, the shop has to take payment, and nobody has time for an outage. So this page gives the number we commit to, what happens if we miss it, how a fault gets found, and how you hear about it. It also says which part of that we have not finished building, because a reliability page that only lists strengths is the least reliable thing on the site.
Reliability is two separate promises. The first is that the system is rarely down. The second is that you are told quickly and plainly when it is, which is the one most vendors are vague about and the one that decides how a Saturday actually goes.
On the first, the commitment is 99.95% monthly uptime for paid plans, written into the Service Level Agreement and backed by service credits on a published schedule when we miss it. Underneath the number is the ordinary engineering that holds it up: a modular architecture on PostgreSQL and Redis, real-time error tracking across the frontend and the API, uptime monitoring, automated anomaly detection, and tenant isolation so one club's traffic or fault stays that club's. Performance targets sit beside availability and are labelled as targets, because that is what they are: sub-second page loads at the 95th percentile and API responses under 200 milliseconds.
On the second, an incident is published in real time to the clubs it affects. Incidents carry a severity and a scope, so a problem touching one region, one tier, or three named clubs is shown to those clubs and not to everyone else, and a scheduled maintenance window can be posted ahead of time and expire on its own. Staff see it as a banner in the platform, arriving the moment it is posted. Security incidents are classified, contained, and communicated within 72 hours in line with GDPR, with affected clubs contacted directly.
That second promise used to have a hole in it, and this page said so: a banner inside the application cannot help the person who cannot reach the application, which is exactly the moment they most want an answer. There is now a public status page at linksmeridian.com/status, readable without signing in, carrying platform-wide incidents and the last week of history. It is deliberately narrow. It shows incidents we have published, not a wall of per-service green ticks and an uptime percentage, because we do not yet measure those continuously and a dashboard that measures nothing is worse than no dashboard. It also shares infrastructure with the platform, so a cached copy is what you would read during a serious origin outage. Both of those are on the list to improve, and both are written down here rather than discovered by you on a Saturday.
How a fault is found, and how you hear about it
Vendors usually describe the first half. The second is the one you experience.
How we find out
Monitoring and detection
Mostly before a club notices, which is the point of running any of it.
- Real-time error tracking across the member app, the admin surface, and the API
- Uptime monitoring against a health endpoint on the API
- Automated anomaly detection that flags a pattern before it crosses a threshold
- A nightly finance integrity job that catches ledger drift on its own
- Tenant isolation enforced platform-wide, so faults do not cross between clubs
- A modular architecture on PostgreSQL and Redis
- Page loads under one second at the 95th percentile (target)
- API responses under 200 milliseconds (target)
How you hear
Incident communication
What reaches your staff on the day, and where it currently falls short.
- A live banner in the platform, pushed over a socket as soon as it is raised
- Severity on every incident, so a notice reads differently from an outage
- Scope on every incident: all clubs, specific clubs, or a subscription tier
- Scheduled maintenance posted ahead of time, expiring by itself when the window closes
- Manual resolution as well as automatic, so an incident ends when the problem does
- Account administrators contacted directly for anything affecting their club
- Security incidents classified and communicated within 72 hours, per GDPR
- A public status page at linksmeridian.com/status for anyone who cannot reach the application
The outcome for your club
A number, in the contract
99.95% monthly uptime for paid plans, in the Service Level Agreement, calculated openly as total minutes less downtime.
Service credits when we miss
Falling below the threshold puts credits on the account on a published schedule. A commitment with no consequence attached is an adjective.
Faults usually surface before you call
Error tracking across the frontend and the API, uptime monitoring, and automated anomaly detection mean most problems are being worked before a club rings up.
Incidents go only to the clubs affected
Every incident carries a severity and a scope, so a fault touching one tier or three named clubs reaches those clubs. Nobody else gets an alarm about something that is not happening to them.
One club's bad day stays theirs
Tenant isolation is enforced across the platform, so a traffic spike or a fault in one club's data does not become another club's Saturday.
We publish what is missing
The public status page is live and readable without signing in. What it deliberately does not show is per-service health dots and an uptime figure, because we do not measure those continuously yet — and this page says that plainly rather than letting you discover it during an outage.
Five ways a Saturday goes wrong, and what happens next
The useful question is not whether a platform ever fails. It is what the next twenty minutes look like.
Every incident carries a severity, a scope, a start, and either an end time or a manual resolution, so the record of what happened survives the day it happened. What is missing is the public view of that record, and it is on the roadmap.
What actually happens on a bad morning
It is detected
Usually by error tracking or the uptime monitor, well before a phone rings. Anomaly detection covers the slower failures that never throw an exception.
It is scoped
Severity and blast radius first: everybody, one tier, or a named list of clubs. Getting this right is what stops an alarm reaching clubs who are fine.
It is published
An incident goes up and the banner appears for the affected clubs, live, without anyone refreshing. Staff see it where they are already working.
It is worked
Contained first, fixed second. Where a club's data was touched, what was touched is established before anyone is told it is over.
It is closed
Resolved manually when it is genuinely finished, or automatically at the end of a scheduled window. The incident record keeps its own history.
You are told what happened
Administrators at affected clubs are contacted directly. For a security incident that runs within 72 hours under GDPR, with impact and remediation.
What a reliability promise should contain
What's included
Common questions
Do you have a public status page?
Not yet, and it is the first thing on this page worth knowing. Our incident system is real and works well for anyone signed in: incidents carry a severity and a scope, and a live banner reaches the clubs affected. What does not exist is a public page anyone can load without an account. The weakness is obvious and it is the whole reason a status page matters: if the platform is unreachable, a banner inside the platform cannot tell you so. Until it ships, the answer to "is it just us?" is a call or an email to us, and we will tell you plainly. It is on the roadmap and this page will change when it is live.
What uptime do you commit to?
99.95% monthly for all paid plans, written into the Service Level Agreement and not merely described in a sales conversation. It is calculated as the total minutes in the month less downtime, and the SLA is published on the site so you can read the definition before you sign rather than after something has gone wrong.
What happens if you miss it?
Eligible plans receive service credits on a published schedule, with the tiers set out in the Service Level Agreement, and credits are requested within 30 days of the incident. A commitment with no consequence behind it is just a number in a brochure.
How would our staff find out there was a problem?
A banner inside the platform, appearing live over a socket rather than waiting for somebody to refresh. It reaches your staff where they are already working, which on a Saturday morning is the pro shop screen. It shows only if the incident's scope includes your club, so you are not alarmed by a fault affecting somebody else.
Do all clubs get told about every incident?
No, deliberately. Every incident carries a scope: all clubs, a specific list of clubs, or a subscription tier. A fault affecting three clubs reaches three clubs. Broadcasting every problem to everybody trains people to ignore the banner, which is worse than not having one.
How is planned maintenance handled?
It is posted ahead of time with a start and an end, so it can go up days in advance and appear when the window opens. It clears itself when the window closes, and it can also be resolved by hand if the work finishes early. Scheduled work should never be the thing that surprises a club on a Saturday.
How do you find problems before we do?
Three ways, and they catch different things. Real-time error tracking runs across the member app, the admin surface, and the API, so an exception arrives with its stack and the release that introduced it. Uptime monitoring runs against a health endpoint on the API. Automated anomaly detection covers the slow failures that never throw an error, and a nightly integrity job runs over the ledger specifically, because accounting drift is the kind of fault nobody notices for a month.
Can another club's problem affect us?
Tenant isolation is enforced across the platform, so another club's traffic spike or corrupted record does not reach your data or your Saturday. This is a structural property rather than an operational promise, which is the version worth having.
Are the performance numbers real or aspirational?
They are targets and they are labelled as targets on this page, which is the honest description. We aim for page loads under one second at the 95th percentile and API responses under 200 milliseconds. A vendor quoting a latency figure as an achievement without saying how it was measured is telling you very little.
What happens with a security incident specifically?
Classification and containment come first, then communication within 72 hours in line with GDPR. Affected clubs are contacted directly with what happened, an impact assessment, and the remediation. The security page sets out the wider posture, including encryption, access control, and the sub-processor list.
Where can we read the actual terms?
The Service Level Agreement is published on this site, alongside the contract promise, the privacy policy, the sub-processor list, and the data processing agreement. None of them require a sales conversation to obtain, which is the point of publishing them.
Has the platform had a major outage?
We are a young platform and we are not going to make a claim about a track record we have not yet had time to build. What we can point at is the machinery: a published commitment with credits behind it, monitoring that finds faults, an incident system that scopes and publishes them, and a page like this that names the part we have not built. Judge the arrangement rather than a number we cannot yet evidence.
What should we ask any golf software vendor about reliability?
Four things. What is the uptime commitment and where is it written down? What happens when you miss it? How would we find out there was a problem, and would that channel still work if your platform were unreachable? And what have you not built yet? The last one tells you the most, because every vendor has an answer and only some of them will give it to you.
Where does the incident record live afterwards?
Each incident keeps its title, body, severity, scope, start, end, and how it was resolved, so what happened in March is still legible in September. The missing piece is the public view of that history, which is the same roadmap item as the status page.
Who do we contact during an incident?
Your usual support channel, and administrators at affected clubs are contacted directly instead of being left to notice. Until the public status page exists, contacting us is also how you confirm whether a problem is ours or local to your club, and we would rather you asked early than sat waiting.
Related pages
Service Level Agreement
The uptime commitment, the credit schedule, and the incident terms.
Security
Encryption, access control, incident response, and GDPR posture.
Sub-processors
Who else touches your data, and what each one does.
Our contract promise
The commitments behind the platform, and how to test them.
Data ownership & exit
What leaves with you, in what format, at no charge.
Demo checklist
Ask to see failover and status history on the call itself.
The commitments behind the platform
This promise sits inside a wider set we publish rather than reserve for a sales call.
Find us on G2, Capterra, and GetApp.
Ask us the reliability questions before you sign
The commitment, the credits, and the gap are all on this page. Free 30-day trial, and we will answer the awkward ones straight.