My Website Stopped Working. What Do I Do in the First Hour?
Your booking system, client portal or online shop stops working. Who to call, what not to touch, what to tell clients, and what to prepare beforehand.
- Reliability
- Provider Outage
- Monitoring
- HARDEN
In short
- In the first hour the order matters more than the speed: call one named person, change nothing in a panic, find out whether the fault is yours or your provider's, and tell your clients.
- A ready two-sentence message to clients keeps trust while the fault is being found.
- Before anything breaks, have four things written down: the services your site stands on, who holds access (you included), a one-page plan, and a check that warns you before clients do.
- In our own case, a client's customers could not log in for just under four hours; the cause was an outside provider, we changed nothing, and the same evening we added a check every 5 minutes.
Imagine a Monday morning. Your online booking page shows an error, three clients phone to say they cannot book, and your developer's phone is off. It could just as well be your accounting firm's client portal that will not open, or an online shop that takes orders but hangs at payment.
Every hour like that costs you bookings, orders and a little trust that is slow to win back. What you do in the first hour decides more than how fast the fix comes.
Think of a burst pipe, not a fire drill
When a pipe bursts in your office, you do not start tearing out walls. You shut the tap, find out whether it is your pipe or the street's, tell the people affected and call the plumber.
A website or app that stops working deserves the same order. The urge to do something fast is the dangerous part. Most of the damage I see comes from changes made in panic, not from the original fault.
The first hour, step by step
1. Call one named person
Not a group chat, not three people at once. Call whoever your plan names: a developer, an agency, your IT person.
Say what you see: which page, what error, since what time, what you have already tried. Write the time down. You will need it later.
2. Touch nothing in a panic
Do not restore an old backup. Do not reinstall anything, change passwords, delete plugins or click "update all". Each of these can add a second problem to the first, and if the system then recovers, nobody knows what fixed it.
If someone who understands the system tells you to change something, fine. The rule is against guessing.
3. Find out whose problem it is
You do not need technical knowledge, only three questions.
- Did anyone change anything since it last worked? An update, a new plugin, a redesign. If it broke right after, your own change is the first suspect. If nothing changed and it worked this morning, look outside.
- Does it fail for everyone? Open the page on your phone using mobile data, and on a colleague's computer. If only your own machine fails, the problem is probably your machine.
- What does your provider's own dashboard say? The public status page is a start, but it describes the provider's platform, not your account. One database provider's status page, for example, lists its components and regions. It does not know that your project is the one in trouble. Also check that your domain and hosting plan are paid and not expired.
4. Tell your clients, in two sentences
Do not wait until you know the cause. Silence feels worse to a client than a short honest note. Keep this text ready:
We have a technical fault with online booking and we are working on it. You can still reach us by phone on [number], and we will tell you as soon as it works again.
Do not promise a time you cannot keep, and do not blame the provider by name. Clients care that you know and are acting.
What this looked like for us
We had a morning like this with one of our clients, and it taught us which of the steps above matter most.
What I took from it: we only learned about the fault from the clients' messages. Now a machine tells us first.
What to have ready before the morning it happens
You can do all of this on one sheet of paper, and none of it needs technical knowledge.
- The list of services your site stands on. Hosting, domain, database, payments, e-mail sending. For each one: its name, what it does for you, which plan you pay for.
- Who holds access. Your own account on every service, plus one trusted person. Not only one developer's private login.
- A one-page "if this happens" note. Who to call, what to check first, what not to touch, and the client message above.
- A check that warns you before clients do. An automatic test that opens your page or tries a login every few minutes and messages you after two failures in a row. Ready-made monitoring services exist for the simple version, and a developer can build a deeper one that tests a real booking or login.
A check like that is the difference between you finding out and a client finding out. I wrote about the same gap in forms that quietly lose leads and in automations that stop without telling anyone.
What to ask your developer, and what a good answer sounds like
You do not have to understand the answers in detail. You only have to hear whether there is an answer.
| You ask | A good answer | A bad answer |
|---|---|---|
| What does our site stand on? | A written list with names, purpose and plan for each service | "It is all set up, do not worry" |
| Who has access, and do I? | You own the accounts, a second person has access, it is written down | "I have all the passwords" |
| How will we know before clients do? | An automatic check every few minutes that messages you | "Clients will tell us" |
| What do customers see if a provider is down? | A clear "temporarily unavailable" page and a plan | "That does not happen" |
| Can we go back to yesterday's version? | Yes, it was tested, and it takes about this long | "In principle, yes" |
Five things to do this week
- Write the list of services your site or app stands on, one line each.
- Check that you personally can log in to each of them, and name a second person who can.
- Write the two-sentence client message and save it where your team can find it.
- Ask your developer how you would find out about an outage before clients do.
- Put the answers on one page, add the phone numbers, and share it with your team.
If step 2 turns up a service you cannot get into, that is your first finding. It is much better to find it on a quiet Tuesday than in the middle of a fault.
How we help
I work in this order: analysis first, then automation of the whole process, then the checks that keep it honest. Our method is called HARDEN. In the Break phase we make a system fail on purpose before your clients do, and in the Monitor phase we watch it afterwards. The full method is described here, and it is what process automation means at Marinext AI. How we work with clients is also set out in a standard we publish (in Bulgarian).
Your next step is small. Open a blank page tonight and write the first line of the list: the name of the service your most important page stands on.
Questions and answers
My website or app stopped working. What should I do first?
Call the one person named in your plan and tell them what you see and since when. Do not restore, reinstall or change passwords in a panic. Then work out whether the fault is yours or your provider's, and send your clients a short message.
How can I tell if the problem is my provider or my own system?
Ask whether anything was changed since it last worked, whether it fails for everyone or only for you, and what your provider's own dashboard says. If nothing changed and it worked this morning, suspect something outside your system.
A provider's status page says everything is fine. Can I relax?
No. A public status page describes the provider's platform in general, not your individual setup. Test your own page the way a client would.
What should I prepare before something breaks?
Write down the list of services your site stands on, make sure you and one other person hold access, keep a one-page plan, and set up an automatic check that messages you before clients do.