Service Level Agreement

Service

The Xamina web application and its API, excluding anything you host or any third-party system you connect to it.

Available

The Service responds successfully to a health check from our external monitoring, from at least two locations, within the response threshold below.

Downtime

Any full minute in which the Service is not Available, excluding Excluded Events. Measured in whole minutes across the calendar month.

Monthly Uptime

(total minutes in the month − Downtime) ÷ total minutes in the month, expressed as a percentage.

Excluded Event

Anything listed in section 4, which does not count as Downtime.

We commit to a Monthly Uptime of at least 99.5% for the production Service.

For context, at 99.9% the allowance is roughly 43 minutes of Downtime in a 30-day month; at 99.5% it is about 3 hours 39 minutes. Pick the figure you can actually hold on your current architecture — an SLA you breach every quarter costs more in credits and credibility than a lower number you always meet.

Response threshold: a health check that does not answer within 10 seconds is treated as a failure.

• By our external monitoring, which checks from at least two independent locations. A failure is only counted when more than one location agrees, so a single monitoring node’s own network problem is not recorded as our outage.
• In whole minutes, over a calendar month, in UTC.
• Against the production environment only. Staging, sandbox and preview environments carry no commitment.

We will provide the underlying measurements on request when you raise a credit claim. If your own monitoring disagrees with ours, send us what you recorded and we will reconcile it rather than simply asserting our figure.

The following are Excluded Events:

• Planned maintenance announced at least 5 working days in advance, inside a published window. We aim to avoid windows that overlap a sitting you have booked.
• Emergency maintenance to address a security vulnerability, announced as early as is safely possible.
• Failure of something outside our control: your network, your device, your identity provider, a candidate’s webcam or internet connection.
• Failure of a third-party service we depend on, where the failure is theirs and not our configuration of it.
• Suspension for non-payment, or for breach of the Acceptable Use Policy.
• Your own misconfiguration, or use of the API outside published rate limits.
• Force majeure.

Note the honest limit: supervision depends on a candidate’s own camera and connection. We commit to the availability of our Service, not to the quality of somebody’s home broadband.

Response means a human has picked it up and replied, not that it is resolved. Support hours are 09:00–17:00 UK time, Monday to Friday, except for P1.

A sitting in progress is always P1. An exam window does not wait for office hours, and treating it as a normal ticket is how a cohort loses a paper.

If we miss the commitment in a calendar month, you may claim a credit against the monthly fee for the affected service:

• Claim within 30 days of the end of the affected month, to info@xamina.io, with the dates and times you observed.
• Credits are applied against future fees. They are not paid in cash.
• Total credits in any month are capped at 100% of that month’s fee.
• Service credits are your sole remedy for missed availability, except where the Master Services Agreement gives you a right to terminate for persistent failure.

Persistent failure. If we miss the commitment in three consecutive months, you may terminate for cause without penalty and receive a pro-rata refund of prepaid fees.

• Backup frequency: the database and the uploaded files are backed up every night, and the last 14 nights are kept. The hosting provider also takes a daily snapshot of the whole server. We do not offer point-in-time recovery, so we cannot restore to a chosen minute.
• Recovery Point Objective: 24 hours — the most data we would expect to lose. This is the age of the latest nightly backup.
• Recovery Time Objective: a target of 8 hours — how long restoring service should take. Rebuilding the platform on another server from the off-site copy was rehearsed on 31 October 2026: the data and the services were back in under three minutes, before the time it takes to create the server and point the domain at it.
• Restore tests: every week the latest nightly backup is restored into a scratch database and checked against the live one, and the off-site copy is restored and checked for its age, its tables and its files. Restoring a server snapshot has not yet been rehearsed.
• Where backups are held: on the server, and every night an encrypted copy goes to a second data centre of our hosting provider, kept for 14 nights. The provider also holds daily snapshots. Losing one data centre loses neither copy; losing the provider’s account would lose both.