Fail-safes and resilience
Three fail-safes, and none of them need us.
A clinic should never lose an afternoon because something outside the building went down. The records are protected as they are written, the software keeps working when everything else fails, and a whole workspace can be rebuilt from a copy you own.
- One — as it is written. Encryption and integrity checks happen at the moment of saving, not afterwards.
- Two — nothing in the way. No server sits between a clinician and a patient record, so there is nothing to fail over to.
- Three — back on your feet. A daily encrypted copy, thirty days of history, restored from your own account.
Fail-safe one
Protection while the record is being written.
The cheapest failure to survive is the one that never happens. This layer is about the moment of saving — before anything needs failing over or restoring.
Encrypted as it lands.
The whole local record store is AES-256-GCM encrypted, with the key held in the operating system’s own secure store rather than a file somebody has to look after.
A tampered file refuses to open.
The encryption is authenticated, so a modified record fails rather than handing back altered data. Silent corruption is the failure that does real harm, because nobody sees it.
Two people cannot overwrite each other.
Every record carries a revision. If it moved while you were typing, the save stops and says so instead of quietly winning.
Unfinished work survives.
A half-written invoice, patient, task or message is kept as you type and is still there after a lock, a sign-out or a crash.
Fail-safe two
Nothing in the path of care.
Most software answers an outage with a second server. We answer it by not putting a server in the way. The workspace runs on the computers the clinic already owns, so the things that usually take a practice offline cannot reach it.
Our outage is not your outage.
If this website is down, if our services are down, if this company stops existing — the clinic opens LogBlues and sees patients. The records are already on the machines in the building.
The licence check fails open.
If the entitlement service cannot be reached it is treated as valid, never as expired. A problem at our end can never lock a clinic out of its own records.
The internet is optional.
Charting, scheduling, notes and invoices all work with the connection gone. That is the ordinary way it runs, not a reduced mode it falls back to.
One person is never the single point.
A second administrator and a named beneficiary mean a lost phone or a lost mailbox does not strand the practice. Nobody here has to be involved.
Fail-safe three
Rebuilding from a copy you own.
The building burns, the drive dies, or ransomware takes the machine. This is the layer that gets a practice back, and it runs without asking us for anything.
A copy a day, on its own.
One encrypted copy goes up every day, on every plan. It is encrypted on the clinic’s own computer before it leaves, so what we hold is unreadable to us.
Thirty days to go back to.
The newest thirty copies are kept, so recovery is not only from last night — it is from whichever day the records were still right.
Your account is the key.
Install on any Windows machine, sign in to the owner account, restore. There is no key file to have lost in the same fire as the computer.
Proven on every build.
Back up, lose everything, restore, verify — run automatically each time the software is built, along with the case that matters most: a corrupt copy refuses rather than half-restoring.
Why three
Each one catches what the last cannot.
Encryption at the moment of writing does nothing for a stolen laptop. Running without a server does nothing for a drive that dies. A copy from last night does nothing about a record that was quietly corrupted a month ago. Layered, each covers the gap the one before it leaves.
If you are used to comparing these on a datasheet, the same three layers under their usual names:
| In LogBlues | The usual name | What it covers |
|---|---|---|
| Protection while writing | Continuous data protection | Loss and corruption, before recovery is needed |
| Nothing in the path of care | Local-first availability | Outages, connectivity, and us |
| Rebuilding from your copy | Automated disaster recovery | Hardware loss, theft, fire, ransomware |
One thing we do not claim: multi-region server failover. It is on the roadmap and it is not built, and a fail-safe page is the last place to describe something that does not exist yet.