Think Build Implement Repeat
SaaS & Product

What to Do and Say When Your Product Is Down

Last updated:

Communication matters more than duration

A two-hour outage with clear, frequent updates does less damage than a forty-minute one where customers were left guessing. People can plan around a problem they understand; they cannot plan around silence.

This is the single highest-return thing a small team can get right, and it costs nothing but discipline.

The first message, within minutes

“We are aware of an issue affecting logins. We are investigating and will update by 10:30.” That is enough. It does not need a cause, a fix or an apology paragraph — it needs to exist, quickly.

Naming the next update time is what converts anxiety into waiting. Then meet it, even if the update is that you have nothing new.

Keep updating on the rhythm

  1. Every 30 minutes for a customer-affecting outage, whether or not there is news
  2. Say what is affected and what still works — partial availability matters to people
  3. Give a workaround if one exists
  4. Say when you will next update, every time
  5. Confirm clearly when it is resolved, and what customers should do

Where to publish

A status page hosted separately from the system that is down, plus the channel your customers already use. A status page on the same infrastructure as your product is unavailable exactly when needed.

For a small customer base, a direct email may serve better than a status page nobody has bookmarked.

Afterwards: an honest explanation

Within a few days, publish what happened, why, what you have changed and what it means for the future. Plain language, no blame, no minimising.

Businesses that do this well come out of an incident with more customer confidence than before. Businesses that publish nothing leave customers assuming the worst about competence.

Keep the internal process light

One person coordinating and communicating, others fixing. The commonest failure in small teams is that the person best placed to fix it is also answering customers, which slows both.

Agree this in advance. During an incident nobody negotiates roles well.

Frequently asked questions

Should we admit fault?

Say what happened accurately. If it was your error, saying so plainly earns more trust than a passive account of things having occurred. Take legal advice where liability is genuinely at stake.

Do we need a status page?

If customers depend on your system daily, yes — it reduces support contact substantially during incidents. For a small customer base, direct communication may be enough.

What about outages caused by our suppliers?

It is still your outage as far as customers are concerned. Communicate it as yours, name the cause factually, and say what you are doing about it.

How much detail should the post-incident write-up include?

Enough for a customer to understand what happened and believe you have addressed it. Deep technical detail is optional; honesty about cause and remedy is not.

Keep reading

No plan for the first ten minutes of an outage?

The template message and the update rhythm take an hour to agree. Worth doing before you need them.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

SaaS DevelopmentCustom Software Development