1. The short version
- Crews keep working when RailOps is down: their phones keep recording and send everything when it is back. Bad orders, blue signals, releases and departures go by radio and paper until then.
- Your Directors and Trainmasters are e-mailed when RailOps has not answered for five minutes, and again when it is back.
- A bad release is reversed in minutes. A lost database is rebuilt from the previous night's copy within hours.
- These are the targets we can meet today, stated as targets. The subscription agreement says what is warranted.
2. Where RailOps runs
The applications are delivered by Netlify. Each railroad's database, sign-in and server functions run on Supabase, on Amazon Web Services in the United States (us-east-2 unless your Order Form says otherwise). Every night a copy of your database is taken to separate storage (Backblaze B2, US East), and every month we restore a copy to prove it works. E-mail goes through Resend; AI features through Anthropic (and Google, on the Demurrage Calculator). Each of those providers publishes its own status page; ours lists them: Netlify, Supabase, AWS.
RailOps is information technology on your people's phones and office computers. It connects to no signalling, control, interlocking or locomotive system, and it issues no movement authority. An outage of RailOps is an outage of a record-keeping and communication tool, which is why the steps below are about records and communication.
3. What happens when RailOps is down
| Part | During the outage | When it is back |
|---|---|---|
| The crew application on a phone | Opens from the installed copy with the day's work downloaded ahead; every report, car move and check-in a crew makes is kept on the phone (the outbox); the status line says "RailOps isn't answering right now" rather than "no signal" | The phone sends its outbox in order; the jobs board shows "Car moves not made" and when each phone was last heard from |
| Bad orders, holds, hazmat inspections, blue signals, releases, departures | By radio and on paper, under your operating rules, as before RailOps | Entered from the paper by the people who made them |
| Switch lists and work orders | The last printed or phone-held list stands; new lists by radio and paper; hazardous materials move with the paper shipping papers the regulations require to be on the train | Lists entered or imported; the paper kept as the record |
| Customer (industry) requests | By phone and e-mail to the office | Entered on Industry Moves |
| Training, Part 243 records, paperwork, reports | Not available; a copy of the records remains with us (the nightly copy) and with you (your exports) | Available again; nothing is lost that was saved before the outage |
| The portal and the customer site | If the sites themselves are down (Netlify), nothing loads; if only the database is down, the sites load and say so | Normal |
4. How you are told
- Within five minutes: our health check runs every five minutes; when two checks in a row find the database not answering, every Director and Trainmaster of your railroad is e-mailed "RailOps is down, crews can keep working", with what the phones keep and what goes by radio. A blip under five minutes sends nothing.
- While it lasts: we send what we know and when we expect it back, and an update at least every hour during a working shift.
- When it is back: a second e-mail, how long it was down, and what to look at on the jobs board. The bell in RailOps rings for your Directors and Trainmasters the first time one of them opens it.
- Who is on the list: each Director's and Trainmaster's own application keeps them on it; anyone whose role changes or who has not opened RailOps in thirty days drops off.
5. Recovery: what we can do today
| Scenario | What we do | Target |
|---|---|---|
| A release of ours breaks a screen | Publish the previous good build (one step, no rebuild) | Minutes |
| The hosting provider or the database provider has an incident | Wait with you; their engineers fix their platform; we confirm your data and the phones' outboxes afterwards | Theirs; historically minutes to a few hours |
| Your database is corrupted (a bad migration, an operator error) | Restore the previous night's copy into a new project and point your applications at it | Recovery point: up to 24 hours of data, re-entered from the phones' outboxes and the paper. Recovery time: 8 hours during a working day |
| Our hosting or database account is lost (a provider failure or a takeover) | Rebuild the applications from source and the database from the off-site copy with a new provider account | Recovery point as above; recovery time: 24 hours |
| An AI or e-mail provider is down | Nothing: every AI screen has a by-hand path, and switch lists download as PDF when e-mail cannot be sent | No outage of RailOps |
Point-in-time recovery (a recovery point of minutes rather than a day) is available as an add-on on your Order Form.
6. Planned maintenance
Database changes that need RailOps to pause are made in a standing window, Sundays 02:00 to 04:00 Central time, with at least two business days' notice by e-mail to your Directors and Trainmasters, and are usually under ten minutes. Most updates need no pause: the applications update themselves on the next visit. Emergency security fixes may be applied outside the window; we tell you as soon as they are done.
7. After an outage
For any outage over an hour we send your Directors a written account within five business days: what happened, when, why, what was done, and what we are changing. Every outage, however short, is recorded in our incident log and reviewed.
8. Your regulatory duties, and our help
Records you keep in RailOps to meet federal rules (training and qualification under 49 CFR Part 243, inspection and operating records, hazardous-materials shipping papers) remain producible during an outage from your own exports and, within the recovery time above, from our nightly copy. If you are a railroad with cybersecurity reporting duties (the TSA security directives, or the CIRCIA rule when in force), our subscription agreement promises you notice of a security incident within the period it states and our cooperation with your own reports; our incident plan is written to meet that.
9. What is not promised
No availability percentage and no service credits unless your Order Form states them. One person responds today; there is no second responder and no 24-hour cover, and we will not say otherwise on a sales call. The targets above are what we have met in testing and in the incidents we have had; they are targets, not warranties. The subscription agreement governs.
10. Contact
During an outage, reply to the outage e-mail or write to sales@clearlineprotocol.com. The version of this page is continuity-2026-10-29.