Status Pages for AI Features: How to Communicate Outages

When an AI feature fails or degrades, post a short, factual status update within minutes. Say what is affected, what users can do instead, and when you will update again. Do not hide behind vague words, and do not promise a fix time you cannot keep.

AI features need their own wording. They can be partly wrong, slow, or only available for some users. A simple "up or down" label does not describe this.

Why AI features need special care

A classic outage is clear: the page does not load. AI failures are often fuzzy.

• The chat answers, but slowly.
• The assistant answers, but with worse quality.
• The feature works for some users and not others.
• The feature is off on purpose, because the provider is down.

Customers cannot see these states. If you say nothing, they guess. Some will think the whole store is broken, and they will leave.

A status page fixes this. It gives one place to check, so your support team does not answer the same question fifty times.

Set up components first

A status page lists components. Split your store into parts that match how customers think.

Good component examples:

• Online store
• Checkout and payments
• AI shopping assistant (chat)
• AI search and recommendations
• Order emails

Keep AI features as their own components. Then an assistant outage does not make "Checkout" look broken. This keeps the page honest and prevents panic.

Choose clear states

Use a small set of states and define each one for your team.

• Operational: works as normal.
• Degraded performance: works, but slow or with reduced quality.
• Partial outage: works for some users or some functions.
• Major outage: does not work.
• Under maintenance: planned work.

For AI, the "degraded" state matters most. Agree in advance what it means. For example: "answers take longer than usual" or "the assistant uses a simpler fallback mode".

The four stages of an incident update

Each incident moves through the same stages. Write a short post for each one.

1. Investigating. You know there is a problem. You do not know the cause yet.
2. Identified. You know the cause and you are working on it.
3. Monitoring. A fix is in place. You are watching.
4. Resolved. The feature works again.

Post at the start, at each change, and at regular intervals while the incident lasts. If nothing changed, say so. "No change since the last update; we are still working on it" is better than silence.

How to write each update

Use plain words. Write for a shopper, not for an engineer.

A good update has four parts:

• What is affected. Name the feature.
• What users see. Describe the symptom.
• What users can do. Give a workaround.
• When the next update comes. Give a time.

Example: investigating

"Investigating: Our AI shopping assistant is responding slowly or not at all. You can still browse the store and check out as normal. For product questions, please use our contact page. We will post an update within 30 minutes."

Example: cause outside your control

"Identified: The assistant relies on an external AI service that is currently having problems. Our store, search and checkout are not affected. The assistant is turned off for now, and customers are offered email support instead. We will update this note when the provider recovers."

Example: resolved

"Resolved: The AI shopping assistant works normally again. The problem lasted from 10:05 to 11:40 CET. Conversations started during that time may have ended with an error message. If your question was not answered, please send it again or contact us."

Replace the times in these examples with your own facts. Only write times you have checked in your logs.

What to avoid

• Vague words such as "some issues" without naming the feature.
• Technical jargon such as "upstream 503" or "token limit". Say "an external AI service is having problems."
• Blame. Name the provider only if it helps customers, and stay neutral.
• Promises. Do not write "fixed in 10 minutes" unless the fix is certain.
• Claims about data. If a customer message may have been lost, say so plainly. If you are not sure, say you are checking.
• Deleting old incidents. A history of honest posts builds trust.

Special cases for AI

Wrong or low-quality answers

If the assistant gives bad answers, treat it as an incident even if the servers are fine. Turn the feature off or limit it, and say so. Wrong answers about prices, stock or returns can hurt customers.

Partial availability

If the assistant works only in some languages or for some pages, list what works. Customers can then decide whether to wait.

Planned changes

When you change the model or the prompts, you can post a maintenance note. Say that answers may look different for a short time.

Connect monitoring to your status page

Update the status page by hand, or connect it to your monitors. Automatic updates are fast, but they can be wrong, so keep a human in the loop for the wording. Uptrack (from the 2folk team) is one tool among several that offers status pages with monitoring. Check what each option supports before you choose.

Also tell your support team where the status page lives. Add its link to your support auto-reply during an incident.

A quick checklist

• AI features have their own components.
• States are defined and understood by the team.
• Templates exist for investigating, identified, monitoring and resolved.
• Each update says what is affected, what users see, what they can do, and when the next update comes.
• One person owns communication during an incident.
• Support knows the page link.

Frequently asked questions

Do I need a status page for a small store?

It helps, even for a small store. It gives customers one place to check and reduces support emails during an incident. A simple hosted page is enough.

Should I name the AI provider when it is the cause?

You may, but you do not have to. Focus on what customers need to know: what is affected and what to do. If you name the provider, stay factual and neutral.

How often should I update during an incident?

Update when something changes, and at a regular interval otherwise. Many teams use every 30 to 60 minutes. Say the next update time in each post, and keep it.

Should I post about slow answers that last only a few minutes?

Usually not, unless customers notice. Set a clear rule, for example a degraded state that lasts longer than a set time. Too many small posts can hide the important ones.