The SLA Explained
This page is written for everyone — even if you’ve never heard the term “SLA.” It explains what an SLA is, states the Synaptyx commitment, and shows what 99% means in practice.
What is an SLA?
An SLA (Service Level Agreement) is a promise about how reliable a service will be, written down and measurable. The headline number is usually uptime — the percentage of time the service is available and working.
If a service promises 99% uptime, it’s saying: “Over a given period, we’ll be up at least 99% of the time. The remaining ≤1% covers maintenance, incidents, and the unexpected.”
The point of an SLA is to set a clear, honest expectation — and to hold the provider accountable to it.
The Synaptyx commitment
Synaptyx targets a 99% uptime SLA for the core tracking service — the redirect path
(/t/*) and the API.
What 99% actually means
Uptime is measured as allowed downtime over a period. Here’s the “nines” table so you can see exactly what 99% buys, and how each extra nine tightens it:
| Uptime | Downtime / day | Downtime / month | Downtime / year |
|---|---|---|---|
| 99% (our SLA) | ~14m 24s | ~7h 18m | ~3d 15h |
| 99.9% (“three nines”) | ~1m 26s | ~43m 50s | ~8h 46m |
| 99.99% (“four nines”) | ~8.6s | ~4m 23s | ~52m 36s |
| 99.999% (“five nines”) | ~0.86s | ~26s | ~5m 15s |
So 99% means that, across a month, the service may be unavailable for up to roughly 7 hours in the worst case and still meet the commitment. In practice the layered failover usually keeps real downtime far lower — but the SLA is the floor we commit to, not the expectation.
What’s covered
The SLA applies to the core tracking service:
- Redirects — your
/t/*tracking links resolving and redirecting visitors. - The API —
/api/v1/*responding to authenticated requests.
The dashboard and asynchronous features (reports, ad-spend sync, etc.) are best- effort around the same target.
What’s typically excluded
Standard SLA exclusions apply — downtime caused by factors outside the platform’s control isn’t counted against the commitment:
| Excluded | Why |
|---|---|
| Scheduled maintenance (announced in advance) | Planned, communicated windows. |
| Third-party outages | Cloudflare, your DNS provider, Stripe/Polar, ad platforms, your offer’s own servers. |
| Your configuration | A dead offer URL, a misconfigured postback, an expired domain. |
| Force majeure | Events genuinely beyond anyone’s control. |
A common confusion: if your offer’s server is down, your tracking link still redirects correctly — the broken page is the destination’s problem, not Synaptyx’s. The SLA covers Synaptyx doing its job (redirect + record), not the third parties on either end.
How uptime is measured
Synaptyx continuously monitors its own health — and specifically whether redirects can still be served, which is what actually matters to you: are my links working? A public System Status page surfaces this at a glance.
Why 99% is realistic (and often conservative)
The platform is built so the things most likely to break don’t take your links down:
Each layer absorbs a class of failure (see Failover & Outages). The 99% figure is the commitment floor; the layered design aims well above it.
In plain words
- SLA = a written, measurable promise about reliability.
- 99% uptime = up at least 99% of the time; worst-case ~7 hours of downtime a month still meets it.
- It covers Synaptyx redirecting and recording your traffic — not third parties or your own misconfigurations.
- The design targets much better than 99% through global edge delivery and durable, layered redundancy.