Privacy

Short version: no accounts, no tracking, no third-party cookies, no analytics that build a profile of you.

What's logged

The application's own access log records one line per request: the requested URL, the HTTP method and status, the timestamp, and your IP address. It does not contain your User-Agent or your referrer.

The log is written to a file on the server's own disk, rotating at 20 MB with five kept — roughly two to ten weeks of history. It stays on that machine: it is not exported, not sent to any analytics service, and not used to build a profile of anybody. It is read when something needs diagnosing — a slow page, a crawler misbehaving, an outage — and otherwise ages out on its own.

As with any website, the platforms that carry the traffic — Cloudflare and Fly.io's edge (see “Hosting”) — do see your IP, User-Agent, and referrer in transit, in their own transient logs under their own policies. Nothing we operate routinely records them — the one exception is an error report (see "Error reporting" below), which includes request headers. Nothing here is used for analytics or profiling.

“Is this right?” reports

Pressing the report button on a crossing page stores the report: the crossing, the moment being reported about, when the button was pressed, what the page was predicting at that moment, and your browser's User-Agent string. No IP address or identifier is stored on the report, so the accuracy record can't be traced back to a person. (The access log above records the IP of the request that submitted it, as it does for every request; the two aren't joined up, and the log ages out.) Reports are kept indefinitely — they're part of the site's accuracy record.

The barrier calibrator

The calibrator is an optional tool for people who want to stand at a crossing and time the barriers by hand. It isn't linked from the site and search engines are asked not to index it; you only reach it if someone gives you the link. Nothing on the rest of the site records anything about you differently because it exists.

If you record a session, each tap stores: the crossing you chose, the event you tapped (barriers down, train, barriers up, start, stop), the time it happened, your device's raw clock reading and the measured difference between your clock and ours, a direction if you tapped a train, a random session identifier your own device generates, and your browser's User-Agent string. No IP address is stored on an observation, so the measurements can't be traced back to a person — the same caveat as above applies, in that the access log records the requests that carried them and ages out on its own. Corrections are kept alongside the original rather than replacing it, so a session shows what you first tapped and what you later decided you saw.

Your location never leaves your device. The find-nearest button asks your browser for a position and uses it entirely inside the page, to reorder the crossing list by distance and to draw you on the map. The coordinates are not sent to us, not stored anywhere, not saved on your device, and are discarded the moment you leave the page. You can decline the permission prompt and still use everything else; you'll just pick your crossing from the list instead. We never learn where you were, only which crossing you told us you were watching.

Opening the “Which way is up?” map loads the Leaflet mapping library from the unpkg CDN and map tiles from OpenStreetMap and OpenRailwayMap, as the map does; those services see your IP address and which tiles you asked for as your browser fetches them, under their own privacy policies. The tiles are chosen by the crossing's position, not yours, and your own position is drawn on top locally and never sent. Leave the drawer closed and none of it happens — the page falls back to a sketch it draws itself.

Sessions are kept indefinitely. They're the only measurements we have of when a barrier actually moved, they can't be re-derived from anything, and they're what the site's timings get corrected against. A copy is held in off-site backup storage. Rate limiting uses your IP address in memory only, to stop one source flooding the tool — it is never written down.

What's stored on your device

The theme preference (auto / light / dark) and your chosen default crossing (if you star one) are kept in your browser's localStorage; which collapsible sections you've left open on crossing pages is kept in sessionStorage (cleared when the tab closes). None of it ever leaves your device. No cookies are set.

If you use the calibrator, it also keeps the session you're recording and any taps not yet sent in localStorage, so a closure survives a dead signal or a closed tab. That includes the random key that proves the session is yours — it stays on your device and is the reason nobody else can edit what you recorded. A running count of what you've recorded is kept there too, purely so the page can show it back to you; we can't see it and don't hold a copy. Clearing your browser storage mid-session means the rest of that session can't be sent.

Android beta signups

The closed test filled up and the Android app page no longer collects addresses. The emails already given are stored so we can add them to the Google Play tester list — that's how Google decides whose account may install the beta. They are the one piece of data on this site that identifies anybody. They are used for nothing else: no newsletter, no marketing, never shared beyond that tester list, and Google sees them under its own policy once listed. Ask and yours is deleted from both.

App push notifications

If you use a Mind the Gates app feature that updates your lock screen or home-screen widget in the background (such as following a crossing), the app registers a push token with us — an opaque identifier issued by your device's platform (Apple) that lets us send those updates and nothing else. It's stored alongside the crossing you asked about, expires automatically (hours for a followed closure, days for widget freshness), is deleted the moment the platform reports it dead, and is never used for marketing or shared with anyone. Apple processes the deliveries under its own policy.

What's not collected

Hosting and data location

The site runs on Fly.io in their London (LHR) region, behind Cloudflare, which proxies every request and caches static content. Both platforms see standard request metadata (IP, URL, User-Agent) and retain it briefly in their own log streams under their own policies; neither sets cookies here.

Error reporting

When the server hits an unhandled exception, an error report is sent to Sentry so we can diagnose and fix it. The report contains the request URL and method, the request headers minus anything identifying (cookies and IP-revealing headers are stripped — the browser / OS hint and referrer do remain), and the stack trace. Client IP addresses are never included. The server also sends Sentry a once-a-minute "still alive" heartbeat and its own operational error logs; neither contains any visitor data.

Your rights

If you believe we hold data about you that you'd like accessed, corrected, or deleted, get in touch. In practice the only record addressed to you we can hold is an Android-beta signup email, deleted on request as above. Beyond that: we keep no store of IP addresses — your IP appears only in Fly.io's and Cloudflare's own transient log streams, which expire automatically on their schedules and which we can't search or selectively edit — and reports carry no IP or identifier. So there is usually nothing to delete; if you think otherwise, tell us what and we'll investigate.

Changes

If this policy ever changes materially, the new version will be dated and the previous version preserved (it's in the site's version control). Last updated: 10 August 2026.