Dental Office Server Down: The First 4 Hours (Who to Call, What to Check, How to Keep Seeing Patients)

It is twenty to eight on a weekday. The first hygiene patient is already seated, the front desk clicks into the schedule and gets a spinning wheel, then a message that the database can't be found. The second front-desk computer says the same thing. Someone in the back offers to "just turn the server off and on", and the doctor wants to know whether to start cancelling.

This guide is the server-side companion to our guide for when the dental office internet is down. It gives you a timed plan for the first four hours, who to call, what still works on each common server setup, the decisions IT will bring you, a checklist for when the server returns, and a one-page card to print. If your practice already has dental IT support with a monitored server, some of the early steps will already be under way when you call; the rest is still yours.

Is it the server, the network or one computer?

A dental office server problem shows up the same way on every workstation at once: the practice software won't open or can't find its database, while the internet still works. If only one computer fails, it is that computer. If nothing reaches the internet either, start with the network. Two minutes of comparison saves an hour of the wrong fix.

A dental office server is the computer in the closet or rack that holds the practice-management database and usually the imaging files. When it stops answering, every workstation shows the same symptom.

Compare the same task on two computers

Pick one simple task, such as opening tomorrow's schedule, and try it on two practice computers in different rooms. Write down the exact wording of any error. Open Dental's manual, for example, lists "Unable to connect to any of the specified MySQL hosts" as the message a workstation shows when it can't reach the database, and says that "MySQL needs to be running to be able to connect" (Open Dental MySQL troubleshooting, read 30 October 2026). Dentrix and Eaglesoft show their own wording; a photo of the screen is better than anyone's memory of it. If the software works on the server itself but not on a workstation, the same Open Dental page points to a firewall on the workstation path, which is a different fix from a dead server.

What should you do in the first 15 minutes?

In the first 15 minutes, write down the time and the exact error, look at the server's lights without touching anything, call your IT provider, and start paper mode. Don't hold the power button, pull plugs or restart the server repeatedly. One person runs the outage; everyone else keeps the patients moving.

Why "don't restart it" matters

A practice-management server runs a database that is writing all day. Cutting its power mid-write is how a fault you could fix in twenty minutes becomes a corrupted database and a restore from backup. Our guide to safe shutdown and restart steps explains the right sequence for planned shutdowns and power events. During an outage, the safer default is to leave the server alone until your IT provider has looked at it remotely or told you exactly what to press.

Who runs the outage

Name one outage lead, usually the office manager, who makes the calls and keeps the notes. Everyone else keeps patients informed and leaves the server and workstations alone; two people calling two vendors with two versions of the problem slows everything down.

Who should you call: your IT provider or the software vendor?

Call your IT provider first. They look after the server hardware, Windows, the network and the backups, and they can bring in the software or imaging vendor once they know which layer failed. Call the practice-software vendor directly only if your agreement says so, or if your IT provider asks you to open a ticket with them.

The split between vendor and IT is often blurry in practice. Our guide to when to call the software vendor and when to call IT goes through it symptom by symptom, and Legend's platform pages for Dentrix IT support, Eaglesoft IT support and Open Dental IT support describe what sits on the IT side for each.

What to say on the call

Give observations, not guesses:

1. 1. What you saw: the exact message, on which computers, with a photo if you can send one.
2. 1. When it started, and the last time anything worked normally.
3. 1. What is affected: scheduling, charting, imaging, payments, phones.
4. 1. What changed recently: an update last night, a power flicker, a new device, a moved cable.
5. 1. Who to call back, on which number, and who in the office can open the server room.

"The server is down" is a conclusion. "Every front-desk computer says the database can't be found since a few minutes ago, websites load fine, and the server's front light is amber" is something an engineer can act on. Our dental IT support ticket checklist shows how to describe the problem as an observation for any kind of ticket.

How do you keep seeing patients without the server?

Most practices can keep seeing patients on paper for visits that need no new imaging and no look back at the chart, such as many hygiene visits and planned work with a printed treatment plan. What still works depends on where your schedule, charts and images live, so check your setup in the table below before you start cancelling.

Where a cell says "often", the answer depends on how your imaging software was set up; some setups let a workstation capture images locally and sync later, and only your imaging vendor or IT provider can confirm yours. Mark your own column once, with IT, and keep it with the printed card.

The paper-mode kit

A paper-mode kit is only useful if it exists before the outage. Keep these in one labelled folder at the front desk:

• • the next day's schedule, printed at close every evening;
• • blank charting, treatment and medical-history update sheets;
• • a way to take card payments that doesn't depend on the practice software, with a paper log of who paid what;
• • a patient call list with phone numbers kept off the server, so the team can reach the afternoon's patients if you need to reschedule;
• • the outage card from the end of this guide, with your IT provider's number written on it.

Which appointments to keep

This is an operational call, not a clinical one, and the dentist makes it. As a starting point, visits that need no new images and no look back at the chart can usually go ahead on paper. Visits that depend on new radiographs, on reviewing prior images, or on complex treatment history are the ones to move. Call those patients first, before they set off, and tell them plainly that the office has a computer problem and their visit is being moved. If your office runs sedation or surgery days, plan those separately: our surgery-day downtime plan covers the oral surgery version.

Hours 1 to 4: repair, restore or fail over?

Between the first and the fourth hour, your IT provider works out why the server stopped and picks one of three paths: repair it in place, restore it from a backup image, or run the office from a recovery copy. Each path has a different wait and puts a different amount of recent work at risk.

The usual causes are a failed disk or power supply, a Windows update that didn't finish, a database service that stopped, or damage to the database files. Much of the diagnosis can happen remotely; our guide on what can be fixed remotely and what needs a visit explains how that decision is usually made.

The one term worth knowing: RPO

NIST defines the recovery point objective as "the point in time to which data must be recovered after an outage" (NIST glossary). In plain words, it is how much of today's work you could lose. If your last good backup ran at close last night, everything entered this morning may need re-entering. That is why the paper notes you started in the first 15 minutes matter, and why the question "what time was that backup taken?" is the most useful one you can ask during a restore. NIST's contingency planning guide, SP 800-34, uses the same idea for planning ahead.

How the backups should be designed, and how often they should be tested, is a separate question. Our guide to dental data backup and recovery covers it, and you shouldn't try to redesign backups in the middle of an outage.

How long will it take?

The wait depends on the cause, on whether parts are needed, on the size of the database and imaging store, and above all on whether a recent backup has been test-restored before. An office that has rehearsed a restore knows roughly how long one takes; an office that hasn't is finding out today. Ask your IT provider for an estimate once they know the cause, and for an update at a set time rather than "when it's done".

What should you check before you trust the server again?

Before the team goes back to normal, confirm the database opens on every workstation, yesterday's and today's entries are where they should be, imaging opens the right patient, and a backup has completed after the repair. A server that has just come back is not yet a server you can rely on.

The backup line is the one most often skipped. A server that failed once is the server most likely to have a weak backup, and the first backup after a repair is the one you'll need if the problem returns next week. Our restore-test scorecard gives you a way to check that a backup actually restores, not just that the job says "completed".

How do you enter the day's work afterwards?

Enter the paper work in a set order, by one or two people, once the server checks above are done: payments first, then clinical notes, then images and documents. Record each note against the real visit, and follow your software's own method for marking entries made after the fact.

1. 1. Payments and adjustments first, so the day's deposit balances and patients aren't billed twice.
2. 1. Clinical notes next, from the paper sheets, by the person who wrote them or with them present.
3. 1. Images and scanned documents last, once imaging has been checked on two computers.
4. 1. Appointments you moved: confirm the new times are in the schedule and the patients were told.

Practice software keeps its own record of who entered what and when. Open Dental's audit trail, for example, logs the date and time of each action and the user who performed it. Don't try to make a late note look as though it was typed during the visit; ask your software vendor how its late-entry features work, and follow your practice's own documentation policy.

What to ask your IT provider about a server outage

After the server is back, ask your IT provider for short written answers. They show whether this was bad luck or a warning.

If this was the second failure in a few years, it is worth asking the bigger question too. Our comparison of replacing the server or moving to the cloud lays out both routes, and Legend's page on server and workstation support covers the hardware side.

HIPAA's Security Rule also expects a contingency plan. The regulation at 45 CFR 164.308(a)(7) lists a data backup plan, a disaster recovery plan and an "emergency mode operation plan" among its implementation specifications. What your plan needs to contain is a question for your compliance adviser; a written version of this guide's first-hours steps is a practical place to start the conversation.

How Legend Networking can help

Legend Networking has 22+ years in dental IT and has served over 3,500 practices since 2004. Its service includes 24/7 monitoring, and the helpdesk is staffed 24/7 at 1-800-794-1588, one general number. Work is handled by in-house engineers, with no outsourced first-level triage, and onsite dispatch is by appointment across served dental markets, remote-first nationwide.

The author, Ian Lynch, has 22 years in dental IT and oversees the NOC, onsite dispatch and client technology roadmaps. Legend holds a 4.8 rating from 173 Google reviews. If a server failure has you reviewing who looks after your IT, the questions in the section above are a fair test for any provider, including us.

Print this: the server-down card

Print this card, fill in the blanks, and keep it with the paper-mode folder at the front desk. It is the whole guide on one page.