Service Level Agreement

Version 1.0 · September 5, 2026

This SLA applies to customers on a paid written agreement that incorporates it. Free and self-serve use is provided on the best-efforts basis described in the Terms of Service and carries no availability commitment.

Why the number is 99.5% and not 99.99%. ArcNautical runs on a single region with no multi-region failover, and it is operated by one person. 99.5% monthly allows about 3 hours 39 minutes of downtime and is a commitment we can actually keep. A higher figure would be a number chosen to win a procurement checklist rather than one we could stand behind at the end of a bad month. If your requirement is genuinely higher, tell us and we will scope the architecture it needs rather than promise it on the current one.

1. Availability commitment

ArcNautical will make the API available at least 99.5% of the time in each calendar month.

Monthly Uptime Percentage is calculated as: total minutes in the month, minus Unavailable minutes, divided by total minutes in the month.

Unavailable means a period of five or more consecutive minutes during which all requests to the production API endpoints return a 5xx error or fail to establish a connection, excluding the circumstances in section 4.

1.1 What is not counted as downtime

Being precise about this matters more than the headline number, because a vague SLA is unenforceable in the customer's favour, not ours.

Individual failed requests that succeed on retry, and rate-limit responses (429) caused by exceeding the agreed limits, are not Unavailability.
Degraded upstream data is not Unavailability — but it is not hidden either. If a sanctions list, registry or inspection source is stale or unreachable, the API keeps serving and every affected response carries the source status and the missing sources rather than quietly returning a lower-confidence answer as if it were a normal one. A screening that cannot be completed to standard is returned as unassessed, never as clear.

2. Service credits

If we miss the commitment, the Controller may claim a credit against the next invoice:

Monthly Uptime Percentage	Credit
Below 99.5% but at or above 99.0%	10% of that month's fees
Below 99.0% but at or above 95.0%	25% of that month's fees
Below 95.0%	50% of that month's fees

To claim, email [email protected] within 30 days of the end of the affected month, with the dates and times of the unavailability and any request logs or error responses you hold. We will respond within 10 business days. Service credits are the sole and exclusive remedy for failure to meet this commitment.

If Monthly Uptime falls below 95.0% in any two months within a rolling six-month period, the Controller may terminate for cause on 30 days written notice and receive a pro rata refund of prepaid fees for the unused term. This is deliberately included: a credit against future invoices is a weak remedy if the service is not working, and an exit right is the one that has teeth.

3. Support

Severity	Definition	First response
1 — Critical	API wholly unavailable, or returning materially incorrect screening results in production	4 hours, 24x7
2 — High	A major function is unusable or significantly degraded with no workaround	1 business day
3 — Normal	A function is impaired but has a workaround; questions on integration or results	3 business days

Business days and hours are those of India Standard Time (UTC+5:30). Severity 1 is answered around the clock. Support is by email to [email protected]; on a paid agreement a named technical contact is given a direct escalation address.

These are response targets, not resolution times. We will not quote a resolution time we cannot control, and a vendor that does is quoting one it intends to miss.

4. Exclusions

The commitment does not apply to unavailability caused by:

Scheduled maintenance, announced by email to the Controller's technical contact at least 48 hours in advance. We target a maximum of four hours per month, in the 18:00 to 22:00 UTC window, which is outside European and Asian business hours.
Emergency maintenance required to address a security vulnerability or imminent data-integrity risk. We give as much notice as the circumstances allow and publish what happened afterwards.
Factors outside our reasonable control, including failures of internet infrastructure, the Controller's own network, or a hosting or CDN provider outage we could not have mitigated.
Use of the API in a way that breaches the Terms of Service, or exceeding agreed rate or quota limits.
Suspension for non-payment following written notice, or suspension required by law or sanctions obligations.

5. Measurement and transparency

Availability is measured by status.arcnautical.com, which is the measurement of record for this SLA. It runs on Cloudflare’s edge, independently of the servers it measures, and probes the website, the application server together with its database, the Voyage Risk API, and a live vessel screen. Every check is published, and so is the number of checks behind every percentage.

How the number is computed, stated so it can be checked rather than trusted: uptime is passed checks divided by total checks over the window. There is no maintenance exclusion, nothing is removed after the fact, and percentages are rounded down — 99.99% is never displayed as 100%. A component is marked degraded after one failed check and down after two consecutive ones; a single failure still counts against uptime. Ninety days of daily history are retained.

The page also carries the incident log, and it is written by the prober rather than by us. An incident opens automatically on the second consecutive failed check, is dated from the first of those failures rather than the second, and closes on the first check that passes. There is no authoring page and no way for anyone here to edit or delete an entry after the fact, which is what makes the incident log and the uptime percentages the same evidence rather than two accounts that could be made to differ.

Two limits we state rather than leave you to discover. The status page runs on Cloudflare and measures through Cloudflare, so a Cloudflare-wide outage would take the page down with the service and neither could report it. And a minute nobody measured is not counted as a good minute — it is not counted at all, which is why the check count is printed beside every figure.

The Controller’s own request logs remain sufficient evidence for a credit claim. We will not dispute a well-evidenced claim on the basis that our own monitoring did not record it — the status page is our measurement, not a ceiling on yours.

6. Changes

We may update this SLA for future terms. For a Controller under a written agreement, the version in effect at the start of the then-current term applies for that term, and no change reduces the commitment mid-term.