Service levels
What we commit to, and what happens when we miss.
Uptime targets, how downtime is actually counted, what a service credit is worth, and how quickly a human answers. Written so it can be checked rather than admired.
Uptime commitments
| Plan | Monthly uptime | Support | Credits |
|---|---|---|---|
| Pilot | Best effort, no commitment | Shared channel, best effort | Not applicable |
| Growth | 99.9% | Business hours, named engineer | Per the table below |
| Enterprise | As agreed in your order form | Priority, contractual response times | As agreed in your order form |
99.9% of a 30-day month leaves roughly 43 minutes. We publish that arithmetic rather than the percentage alone, because “three nines” sounds like a rounding error until you see it in minutes and decide whether you can absorb it during a launch.
How downtime is counted
The definition is where service levels are usually quietly won by the vendor, so here is ours in plain terms.
Downtime means the match endpoint returns 5xx errors, or fails to respond within 10 seconds, for more than 1% of well-formed requests over a five-minute window. We measure at our edge, per region, and the raw measurements are available to you on request — not just the summary.
Not downtime:
- Announced maintenance inside the window described below.
- Failures caused by your own systems, network or configuration.
- A third-party platform outside our control failing — though we will still help you diagnose it.
429responses caused by you exceeding agreed rate limits.- Requests we decline on quality grounds. A capture the engine refuses is a correct answer, not an outage.
- Force majeure.
One thing we will not do: count a degraded-but-responding service as uptime. If the API is returning results but accuracy has regressed because a catalogue or model deployment went wrong, that is an incident and it is treated as one, even though every request is technically a 200.
Service credits
If we miss the committed figure in a calendar month, you are entitled to a credit against the following month's fees.
| Monthly uptime achieved | Credit |
|---|---|
| 99.9% or above | None — commitment met |
| 99.0% to below 99.9% | 10% of that month's fee |
| 95.0% to below 99.0% | 25% of that month's fee |
| Below 95.0% | 50% of that month's fee |
Credits are your sole remedy for missed uptime under the standard terms, and they are capped at that month's fee. We think it is fairer to say that here than to leave you to find it in a clause.
You should not have to ask. If we miss a commitment we apply the credit and tell you, rather than waiting to see whether you noticed. If we ever fail to, claim it within 60 days and we will apply it without argument.
Support response times
| Severity | What it means | Growth | Enterprise |
|---|---|---|---|
| 1 — Critical | Production down, or matches materially wrong for live traffic | 4 business hours | 1 hour, 24/7 |
| 2 — High | A major function broken, no workaround | 1 business day | 4 hours |
| 3 — Normal | Something broken with a workaround, or a catalogue problem | 2 business days | 1 business day |
| 4 — Low | Questions, documentation, feature requests | 3 business days | 2 business days |
These are times to a substantive human response, not to an automated ticket acknowledgement. Business hours are 09:00–18:00 Singapore time, Monday to Friday, excluding Singapore public holidays.
You set the initial severity. We will not quietly downgrade it — if we disagree we will tell you and explain why, and you can push back.
Maintenance
- Announced at least 48 hours ahead, by email to your technical contacts.
- Targeted at low-traffic windows for your region, not ours.
- Capped at 4 hours per month in total.
- Emergency maintenance — a security fix that cannot wait — may happen with less notice. We will tell you as soon as we can and explain afterwards what it was for.
When something goes wrong
Our commitment during an incident is about communication, because that is the part you can actually use while you wait.
- We contain first and investigate second. Restoring your service beats diagnosing it.
- Affected customers are notified without undue delay — we do not wait until we have a complete picture to say something is wrong.
- Updates go out at least hourly for a Severity 1, even when the update is “still working on it, nothing new to report”.
- We tell you what we know, what we do not yet know, and what we are doing. Those are three different things and blurring them helps nobody.
- A post-incident review follows for any Severity 1 — root cause, timeline and corrective actions, shared with affected customers.
Being straight about our stage: a customer-facing status page is still in progress. Until it exists, incident communication is by email to your technical contacts and in your shared channel. That is worse than a status page and we are not going to pretend otherwise — see the security page for the rest of what is and is not in place.
What this does not cover
Service levels are about availability and responsiveness. They are not a warranty of match accuracy for your specific range, and no uptime figure implies one. Accuracy depends on capture conditions, device characteristics, the quality of your catalogue measurements and the product finish — which is why we report it per Fitzpatrick band rather than as a single promise. Clause 11 of the terms sets that out in full.
Contact
Support: support@exacthue.com
Security incidents: security@exacthue.com
Commercial questions about your agreement: partnerships@exacthue.com
This page describes our service levels in plain language. Where it differs from your signed order form, the order form governs.