Fortsæt → Oversigt

Service Level Agreement

This document states what availability the service aims for, how that number is produced, and what you are entitled to when it is missed. It is written to be checkable: every figure below comes from a measurement you can ask to see.

Effective date: 28. aug. 2026

Dette dokument gemmes kun på de sprog herunder, så en oversættelsesfejl ikke kan ændre dets betydning. Den engelske version gælder i tilfælde af uenighed. Tilgængelig på: English Türkçe

1. Availability target

The monthly availability target for the API is 99.9%, measured over each calendar month. That allows roughly 43 minutes of unavailability in a 30-day month.

The target covers the API endpoints and the dashboard. Batch file processing is queued work and is covered by the processing commitment in section 3 rather than by the uptime figure.

2. How availability is measured

A request counts as failed when the API returns a 5xx response or does not respond within the timeout. Errors caused by your own request — an invalid key, an exhausted credit balance, a malformed body, or a rate limit you exceeded — are not failures of the service and are not counted.

Availability is measured from outside the service, not by the service reporting on itself. An internal check cannot report that the machine is down, because whatever would report it is down too. An external monitor expects a regular signal and raises the alarm when it stops.

The health endpoint returns a 503 status when the service is degraded in a way that would produce wrong or empty answers, so a monitor sees the fault even while the process itself is still running. This matters here specifically: without it, a server that has lost its name dataset would keep answering with 200 and an empty result.

3. Batch processing

A batch job that has been accepted is processed to completion or refunded in full. There is no state in which a file is charged but not delivered: credits are reserved when the job starts and settled against the rows actually processed, and a job that fails releases the reservation.

If a worker is killed mid-job, a recovery process returns the job to the queue or, if its attempts are exhausted, closes it and refunds the credits.

4. Exclusions

The target does not apply to:

  • Announced maintenance, communicated at least 48 hours in advance and scheduled outside 08:00–20:00 UTC where possible.
  • Failures of your own network, DNS resolver or client.
  • Force majeure, and failures at an upstream provider that are outside our control and affect that provider broadly.
  • Suspension of an account for non-payment or for a breach of the Terms of Service.
  • The free tier and the public homepage demo, which are provided without an availability commitment.

5. If the target is missed

If measured availability in a calendar month falls below 99.9%, you may request service credits: 10% of the value of the credits consumed that month for availability below 99.9%, and 25% for availability below 99.0%. Service credits are added to your credit balance and, like every credit on this service, they do not expire.

Claims are made by contacting support within 30 days of the end of the affected month. Service credits are the sole remedy under this document.

6. Status and incidents

Current component status is published on the status page. Where an incident affected answers rather than availability — for example a data problem that changed results — it is stated plainly, because a wrong answer delivered quickly is worse than no answer.

7. Contact

Availability reports, claims and questions:

info@namegender.com

Service operator

Operator
NameGender
Contact email
info@namegender.com