Continuity · foot.io

The short version

if you read one thing, read the table

Question	Answer, 6 August 2026
Who runs it?	One person. There is no second engineer, no support team and no on-call rota.
Is there an SLA?	No. Not on any self-serve tier. Enterprise terms are negotiated individually and are the only route to a contractual commitment.
Do you publish an uptime figure?	No. A six-hourly smoke check alarms on failure (since 6 August 2026), but nothing measures availability over time, so any percentage we printed would be invented. /status checks the live service from your browser when you load it.
Is the database backed up?	Yes — automated daily snapshots of the whole database, plus a nightly offsite export of the curated layer that has run daily since 28 July 2026. Point-in-time recovery is off, and the documented seven-day snapshot retention is not confirmed by the platform's API — details below.
Has a restore ever been performed?	No. The recovery times below are estimates, not measurements.
Will someone notice when it breaks?	Automated checks run on schedules from six-hourly to daily and file a tracked issue on failure. Nothing pages a phone. There is no overnight response.
Can I get my data out?	Yes, in a machine-readable form, free, on request — including after you cancel. Limits and reasons are below.
What if you are hit by a bus?	The API keeps answering — it is managed infrastructure, not a machine in a cupboard. Support stops immediately and the data starts going stale within days.

Backups, and what they are actually worth

verified against production, 6 aug 2026

Everything foot.io serves lives in a single managed Postgres 17 project on Supabase, in London (eu-west-2). It is currently about 20 GB. The site is a static build on Netlify. Neither of those is a machine we own or have to keep switched on.

What the managed backups cover

The platform takes an automated snapshot of the database daily. That is a real backup taken by someone other than us, and it is the single most valuable protection foot.io has. It is also the only backup that covers the full corpus of 1,177,209 matches we hold (measured 10 August 2026). One caveat on depth: the plan's documentation says seven days of retention, but our nightly coverage check cannot confirm that figure from the platform's API — on 6 August 2026 it could see six daily snapshots, the newest a few hours old. We state what the check sees rather than what the brochure says.

RPO — what you would lose: up to 24 hours. If a bad write lands at 09:00 and the last snapshot was at 02:00, seven hours of ingestion is gone with it.
RTO — how long you would be down: our estimate is 30 to 60 minutes. A restore takes the database offline and the time scales with size. We have never performed one, so treat that as a considered estimate and nothing more. We would rather print a soft number honestly labelled than a hard one we invented.
Point-in-time recovery is off. It is a paid add-on, and the nightly check that reads the real value from the platform has now reported: PITR enabled: false (checked 6 August 2026). Recovery granularity is the daily snapshot and nothing finer. The same check could not confirm the documented snapshot retention window, which is why this page no longer states one as fact.
Slow damage outgrows the snapshots. Retention is short — documented as seven days, with six snapshots visible to the check on 6 August 2026 — so a corruption that goes unnoticed for a fortnight is outside every managed backup we have. Data-contract checks and a published errata log are the controls for that, not backups.
The backups are not independent of the account. Supabase documents that deleting a project permanently removes its data and its stored backups. So "we have daily backups" is protection against a bad write. It is not protection against losing the account itself.

What we are doing about the part that is not covered

Not everything in the database can be re-fetched. Licence classifications, API entitlements, entity de-duplication adjudications, coverage targets and errata are judgements we made; if they were lost, re-running every importer would not bring them back. A nightly export of exactly that layer to a second location outside the database is now a track record, not a plan: the first successful run was on 28 July 2026 and it has run every day since, every scheduled nightly run from 29 July to 6 August 2026 succeeding. The latest export covers 23 tables, 359,156 rows, about 28 MB, and every run re-reads and re-hashes its own output against a manifest before it counts as a success, so a truncated export fails the run instead of being discovered during an incident.

The 20 GB of matches, events, lineups and statistics is deliberately not in that export, and that is the real gap. It exists in one place. If the project were lost, the schema comes back from version control in under an hour and the curated layer in minutes, but the corpus would have to be re-ingested: it was accumulated over 118 days and 26,445 scheduled runs since 10 April 2026 (measured 6 August 2026), and it is bound by upstream rate limits rather than by compute. Budget weeks for a usable subset and months for parity. That is the honest number and it is why a copy of the full corpus in storage we control — separate from Supabase and separate from GitHub — is the top item on the list at the end of this page.

One thing we are confident about: the schema is fully reproducible. Every table, policy and function is defined by migration files in version control, replayed from scratch on every change, and a job runs daily comparing production against them. If production ever contains something the repository cannot rebuild, that job fails.

Monitoring — and what it does not cover

the gaps are the useful part of this section

Watched

Every scheduled ingestion and check job. A failing run automatically opens a tracking issue — or adds to the open one for that job — but closing it is a human act: recovered incidents are closed in triage, not by the machine.
A six-hourly smoke check (since 6 August 2026) performs the same anon reads a first-time visitor's browser performs, with the published key, and fails loudly when a change silently kills a public page.
A daily import-health job (07:30 UTC) reads the ingestion log and fails on stale sources, missed freshness targets and spikes in quarantined rows.
A daily schema check (07:40 UTC) compares production against the committed migrations.
Data contracts (08:00 UTC) — invariants that must stay at zero, encoding bug classes we have already been bitten by — run daily against production.
/status performs live checks of REST, the metered gateway, the MCP server and data freshness from your browser, against production.

Not watched

No uptime measurement. Since 6 August 2026 a smoke check probes the public read surface every six hours and files an issue on failure, but nothing measures availability or latency over time, and /status only runs when a human opens it. We therefore publish no uptime percentage.
A job that never starts. Several sources block datacentre IPs and are fetched from a dedicated machine. A job there that runs and fails surfaces about a day later; one that never runs at all may not surface.
A workflow whose own configuration is invalid goes red without firing an alert. We proved this rather than assumed it.
Anything outside the CI system — the site build, the CDN, the database platform's own runtime.

Does an alert reach a human? Not reliably, and we checked rather than assumed

A failing job files an issue in our tracker. It does not page anyone and there is no 24/7 response. We verified the notification path on 28 July 2026 instead of trusting the design, and found the issues notified nobody at all — the account was not subscribed to repository notifications — so the alerter now assigns each new issue to the operator, which produces an ordinary notification, not a page. It still depends on one person reading notifications in UK working hours, and the backlog is real: on 6 August 2026 there were 14 of these tracking issues open, the oldest since 29 July. That is the true state of it, and it is precisely why this page offers no response-time commitment.

Two fixes are queued — routing alerts to a channel that actually reaches a phone, and cutting the noise so real ingestion failures are not buried under routine build alerts. Until those are done and stated here, the accurate summary is: problems are found by scheduled checks, and acted on in UK working hours.

Getting your data out

what we will actually do, not what sounds generous

The strongest continuity guarantee is not a promise about us — it is having nothing to escape from. There is no proprietary client and no proprietary format. The API is PostgREST over HTTPS returning ordinary JSON, described by an OpenAPI specification you can download today. Whatever you build against it is portable to any Postgres you can host yourself.

Your account data, on request, within 30 days, free. Contact details, plan, and your usage records, in a machine-readable file. This holds after you cancel and after you stop paying. Email hello@foot.io and say what you want.
What you have already retrieved stays usable. Cancelling a key does not retroactively oblige you to purge a cache you built legitimately under the terms in force when you fetched it.
A bulk dump of the whole database is not a standard entitlement — and here is the real reason. Much of the corpus comes from upstream sources whose terms allow us to serve records through an API but not to hand the set over in bulk. That constraint is theirs, not a lock-in tactic of ours; we publish the licence class of every source and we removed two data types from sale entirely on 28 July 2026 rather than re-serve what we could not defend. Bulk delivery is negotiable under an Enterprise agreement, and only for the subset we can genuinely license.
If we shut down deliberately: 90 days' notice to every paying customer, no further charges from the day of the announcement, and the API stays readable through that window so you can pull what you need under your existing terms. Whatever portion of the corpus we have the right to release openly, we will release openly.

That 90-day commitment covers a planned shutdown, which is the case we can control. It is not a promise we are able to make about the unplanned one. The next section is about that.

If the operator is unavailable

the bus-factor answer, without the reassurance theatre

The bus factor for foot.io is one. No arrangement of words changes that, so here is the specific, mechanical version of what it costs you — which is more useful than being told not to worry.

What keeps running with nobody present

The API and the site are managed infrastructure, not hardware in a flat. Nothing needs a daily restart. If nobody touched foot.io for a month, requests would keep being answered and the site would keep serving; the failure is gradual, not a cliff.

What stops, and how quickly

Support stops immediately. There is nobody else reading hello@foot.io.
Data goes stale, then stops. Scheduled ingestion continues unattended for a while, but not indefinitely: GitHub disables scheduled jobs after 60 days without repository activity, and several sources are fetched from a physical machine that has to be powered on. Expect live results to degrade within days and the rest within weeks.
Nothing fixes itself. A broken importer stays broken. Corrections stop. The corpus does not rot, but it freezes, and a frozen football database is wrong a little more every week.
The end state is a billing lapse, not a crash. The infrastructure is paid by card. If those payments fail for long enough the provider suspends and eventually deletes the project — and, as above, the backups go with it. That is the scenario the offsite copy is meant to survive, and it is the reason it is the top of the list below rather than a nice-to-have.

What genuinely reduces the damage

Everything needed to run foot.io is in one version-controlled repository, not in one person's head: the schema as replayable migrations, every importer, the deployment configuration, and written runbooks for disaster recovery and alerting that name the gaps rather than paper over them. A competent Postgres and Python engineer could pick it up from the repository alone. That is a real mitigation and it is deliberately the first thing we did.

What we have not done, and will not pretend to have done

There is no second person with access to the infrastructure and billing accounts today. No escrow, no named successor, no legal continuity arrangement, no dead-man switch. If you are evaluating foot.io for something where that is disqualifying, it should be disqualifying, and we would rather you learn it here than six months in.

The plan, dated

so you can check whether we did it

In priority order. Each line gets a date on this page when it lands. If something below still reads not started in six months, that tells you something true about how seriously we take this — which is the point of writing it down.

Commitment	State	Detail
Written runbooks for backup, restore and alerting	Done	28 July 2026. They name the gaps; this page is derived from them.
Nightly offsite export of the layer that cannot be re-derived	Done	First successful run 28 July 2026; nightly since, with every scheduled run to 6 August 2026 succeeding. Latest export: 23 tables, 359,156 rows, ~28 MB, verified by read-back against its manifest.
A copy of the full corpus in storage we control, independent of the database platform and of GitHub	Not started	The single largest gap. Closing it is what makes account loss survivable.
Alerts that reach a phone, and less noise around them	Not started	Two small changes. Until then, failures are found by scheduled checks, not by a pager.
A rehearsed restore, with the measured time published here	Not started	Replaces the estimated 30–60 minutes above with a real figure.
A named second person with break-glass access to infrastructure and billing	Not started	The only thing that genuinely changes the bus factor.
A self-service cancellation path, published before the first payment is taken	Not started	Self-serve checkout is not open yet, so nobody is being charged today. You should never need us in order to stop paying us.

How to reach a human

there is one, and it is always the same one

hello@foot.io — the only support channel, read by the person who runs foot.io, in UK working hours. There is no guaranteed response time and we are not going to invent one.
Is it up right now? /status answers that from your browser rather than from a dashboard we control.
Found a wrong record? Report it to the same address; corrections are published in the errata log and the method is documented in methodology.
Need contractual commitments — an SLA, escrow, bulk delivery, redistribution rights, a signed data-processing agreement? None of those exist on the self-serve tiers. They are exactly what an Enterprise conversation is for. Email the same address and say so plainly.

Why this page exists. "It is one person" is the objection most often levelled at small football-data APIs, and it is levelled at us fairly. An unanswered objection is a fear; a stated policy is something you can weigh against a price. Every figure here was checked against production or against our provider's published policy, most recently on 6 August 2026, and anything we could not check is marked as unchecked rather than rounded up. If you find a claim on this page that does not hold, tell us and we will correct the page — hello@foot.io.

Pricing Status How we compare Terms