What happens when cloud veterinary software goes offline

When the internet drops in a veterinary practice, the waiting room does not pause for IT. Reception looks at the practice manager. The vets start writing on paper. The phones still ring. That is not a vendor outage notice. That is your afternoon, your evening, and often your Sunday.

Self-hosting was never really about owning a server. It was about not going dark. Cloud software already won the rest of the argument: someone else does the updates, you are not the backup plan, and you can reach the same file from more than one site. The remaining objection is honest and specific. If the line goes down, does the clinic still work?

For a practice manager, that question is not theoretical. You are the one who has to reconstruct who was seen, what was given, what was charged, and what was promised, from a pile of notes that were never meant to be the record.

What the fallout actually looks like

A typical outage is not dramatic. It is forty minutes of the system feeling slow, then a hard stop. Reception cannot look anyone up. The diary is a screenshot if someone thought to take one, or a printed list from this morning that is already wrong. Clinicians write notes on the back of a consent form. Dispensing is from memory and the bottle in the hand. Payment, if it happens at all, is a card machine in standalone mode and a sticky note.

Then the line comes back, and the real work starts.

Someone has to type the notes in. Someone has to match charges to patients. Someone has to work out whether the afternoon booster was given, or only written down, or given and not written down. Two people will have recorded the same consult differently. A nurse will have started a history that a vet then finished on paper. The till will not match. Clients will ring tomorrow asking what they were told, and the record will still be empty.

That reconstruction is almost always unpaid, almost always after hours, and almost always the practice manager's problem even when other people help. Staff remember it. The next time anyone suggests moving further into the cloud, someone will say: remember the Tuesday we went down.

Paper is not a disaster plan

Writing on paper feels responsible for the first consult. It is a terrible way to run a morning. There is no search, no previous history, no dose check against the record, no audit of who wrote what, and no reliable path from that scrap into the live file. The notes that never get typed in are a clinical risk. The charges that never get posted are a quiet leak. Both land on you.

A printed diary from 8am is already stale by 9.15. Walk-ins, cancellations, and last-minute extras do not wait for the printer. If your outage plan is paper plus a catch-up session, you do not have an outage plan. You have a second job that appears without warning.

Self-hosting moves the outage. It does not remove it.

A server in a cupboard has a different failure mode. You are no longer waiting on the broadband, but you are waiting on a disk, a Windows update, a power cut, or the one person who knows how the backups work. Independent practices did not keep a server in the building because it was elegant. They stayed because at least the consulting room computers could still talk to something on site.

That is a real advantage on a bad line. It is also a job: patching, replacing, restoring, and being the person who gets the 7am call that the server will not boot. Most managers who have lived through both kinds of failure would rather not own the hardware. They would rather the hosted system had an answer for the broadband day.

The gap is not cloud versus a cupboard

The useful choice is not between a managed PMS and running your own kit. It is between a hosted system that stops when the building loses internet, and a hosted system that can keep a limited, practical set of clinic work going on the device in front of you, then catch the record up when you reconnect.

You should not need a second PMS for disasters. Staff will not remember a different product they use twice a year. You also should not need the whole of the software to keep working. Card payments, ordering, reporting, and anything that needs a live third party can wait. The work that cannot wait is seeing the patient in front of you, capturing what happened, and keeping the day moving.

When the line comes back, queued work has to write back to the live record. If two people touched the same thing while you were apart, both versions should still be there. Silently keeping the last save is how notes disappear. You should be able to see who wrote what, and choose, rather than discover a week later that a consult was overwritten.

Questions to ask any cloud supplier

If you are comparing systems, or defending a move you have already made, these are the questions that matter more than another uptime percentage.

• If the internet drops at 10am, what can reception and the consulting rooms still do?
• What is deliberately unavailable, and why?
• When we reconnect, how does queued work get into the live record?
• If two people edited the same notes, what happens to both versions?
• Are we expected to keep a paper fallback as the real plan?
• Can you show this on a tour, or is it a slide?

If the answer is to print the diary, or that they have never gone down, you still do not have a plan. Uptime on the vendor's side does not help if your building loses broadband. A screenshot of a status page does not type the notes in.

What we are building

Vetrics is a hosted PMS. Disaster Mode is the planned answer to the outage: a limited feature set on the device, then full reconciliation, with competing versions kept rather than overwritten. It is in development and not generally available yet. The point of saying that in public is not to sell a switch that does not exist. It is to be clear that the objection is real, and that moving to the cloud is incomplete until it is answered.

Practice managers do not need another argument for cloud software. They need the remaining argument answered. You should not have to run a server in a cupboard, and you should not have to reconstruct a morning from paper because the line went down. Close that gap, and the choice stops being cloud or self-hosted. It becomes cloud, with a plan.