What should an AI startup put on its status page?

List the jobs customers do in the product, such as generating a draft or translating a file, rather than only Website and API. Add the AI model provider as a named row with a link to its own status page. Include integrations customers rely on and a speed target for the main job.

Should I list OpenAI or Anthropic on my status page?

Yes, if your product depends on them. Business buyers usually know your provider already from your subprocessor list or security review. Naming it, and linking to its status page, shows you understand your own dependencies and will be open when one of them fails.

What is the difference between degraded performance and an outage?

An outage means a service is not working. Degraded performance means it works but slowly, with more errors or with weaker results. For an AI product the degraded state is far more common, so it should be reported as soon as customers would notice it.

Where should the status page link go on my website?

Put a Status link in the website footer next to Security and Privacy, at the top of the help centre and API docs, and inside the product where long tasks or errors appear. Add it to your saved support reply so every ticket during an incident points to the same place.

How do I write an incident update for an AI product?

Use four short parts: a title with the affected job and the cause, what customers saw with times, what caused it and what you did, and what changes next. Name the upstream provider if it caused the problem and link to its incident page. Keep each part to two sentences.

Can my status page update automatically when my AI provider has an outage?

Some status page tools can mirror another company's status. Atlassian Statuspage calls these third-party components, and they turn your row yellow or red when the provider reports a problem. You can override the row when the provider's incident does not affect your product.

Status Page Best Practices: Name Your AI Upstream

The status page best practices that matter for an AI product are two: list your model provider as a named dependency, and report slow or bad output as well as downtime. A status page that only says whether your website is up will show green on the afternoon your product stops working.

This matters most when you sell to bigger companies. Their buyers open the status page during a pilot, during a security review and on the day something breaks. A page with one green row tells them they are dealing with a small team that has not thought about failure. Most of them already know you run on someone else's model. Hiding it does not make you look bigger. It makes you look like you hoped nobody would ask.

Green rows on the day translations stalled at string 212

Picture an AI localization tool sold to product teams at mid-size software companies. A product manager uploads the app's strings file, picks German, French and Japanese, and gets back translations that follow the company's glossary. On a normal day a file of 1,480 strings comes back in about four minutes.

One Tuesday afternoon the model provider behind it has a partial outage. Some requests fail. Most just run slowly. Inside the app, a job sits on a progress bar that reads Translating string 212 of 1,480 for twelve minutes. Nothing tells the product manager why. She refreshes, uploads the file again, and now two jobs are stuck.

She opens the status page from the footer. The header reads No incidents reported. Below it are three rows: Website, Dashboard and API. Each one says Operational next to a 90 day bar that is solid green. The page is accurate. The website is up. The dashboard loads. The API answers. The one thing she came to do is broken, and the page has no row for it.

By four o'clock the support inbox holds 37 new tickets. Most of the subject lines are some version of stuck or not loading. Two customers attached a screenshot of the green status page next to the frozen progress bar.

What the founder does between three and six

He answers the tickets himself, because the support hire starts next month. He writes one reply, saves it as a snippet and pastes it into every ticket. It says the team is looking into slow translations. It does not say why, because naming the provider feels like admitting the product is a wrapper.

He checks the provider's own status page every ten minutes. It has shown a yellow Degraded performance banner since half past two. His customers cannot see that, because his page does not point there. He thinks about flipping the API row to yellow, decides it would be wrong because the API is fine, and leaves it green.

The next morning the head of engineering at his largest pilot account sends a short email. It asks which AI provider the product uses and whether there is a backup. The answer has been in the security questionnaire her team filled in six weeks ago. The provider is on his subprocessor list. She knew. What she learned on Tuesday was that he would not say it when it counted.

Down is rare for an AI product. Slow and wrong are the usual failure.

Most status page advice comes from infrastructure companies, where a service is up or it is down. Atlassian's Statuspage, the tool behind a lot of these pages, already gives every component five states: Operational, Degraded performance, Partial outage, Major outage and Under maintenance, as its component guide lists. Founders use two of them.

An AI product fails in the middle states far more often than in the last one. The model answers, but in forty seconds instead of four. It answers, but a long document times out halfway. It answers, but a fallback model gives thinner results. None of that is downtime, and all of it is what your customer notices.

So the rows on your page should be the jobs a customer does, not the parts of your stack. For the localization tool that means rows like these:

Translation. Uploaded files finish and come back translated. This is the row that should have turned yellow on Tuesday.
Translation speed. A plain target, such as most files back in under five minutes, and a yellow state when you miss it.
Glossary checks. Separate from translation, because it may run on a different model or prompt.
Integrations. GitHub sync, the Figma plugin, Slack alerts. Each one fails on its own schedule.
Model provider. Named, with a link to its own status page.
App and sign-in. The old Website and Dashboard rows, folded into one.

Degraded performance is not a softer word for down. It is the honest word for the most common bad day an AI product has. Use it early. A yellow row posted at 2:40 reads as a team that watches its product. A yellow row posted at 5:00, after 37 tickets, reads as a team that was told.

Name the provider. Your buyer already knows.

The usual worry is that a row called OpenAI or Anthropic tells the world you are a thin layer on someone else's model. That worry gets it backwards. An engineering or security buyer at a mid-size company has seen your subprocessor list. Some of them chose you because of the provider. The question they are asking is not whether you depend on a model. It is whether you know what you depend on and will tell them when it breaks.

Cursor shows what this looks like. On October 6, 2026 its status page posted an incident with Anthropic models named in the title. The first update named the exact model, linked straight to Anthropic's own incident page, and listed the parts of Cursor it affected: Automations, CLI, Cloud Agents and IDE. It was resolved a little over three hours later. Nobody reading it came away thinking Cursor was small. They came away knowing exactly what was wrong and where to watch.

You do not have to build this by hand. Statuspage lets you add a third-party component that mirrors another company's status, so your Model provider row turns yellow when theirs does and turns back when they recover. You can still override it when their incident does not touch you. Other status tools have similar features. Check before you build your own.

Naming the provider also makes your own work visible. When the provider is down and your product still returns translations on a fallback model, your page can say so: Model provider, Degraded. Translation, Operational. That pair of rows is the strongest thing a status page can show, because it proves there is something behind the model.

What the green page costs at renewal

The cost does not show up as churn on Tuesday. It shows up later, in who takes the next call and how long the next contract is.

A pilot at a company that size usually ends in a review with more people in the room than started it. Someone from procurement or security joins. They have one incident to judge you by, and the record they will find is a status page that said No incidents reported on the day 37 tickets came in. A vendor that looked like a risk once gets a shorter contract, a smaller first order or a request for another reference.

This is the same problem as the rest of the site, in a place founders forget to look. A buyer who has sat through demos from vendors three times your size reads your status page the way they read your homepage, in a few seconds and from the surface. The security pages and trust centres that win reviews work the same way: they answer the hard question before it is asked. Investors look at the footer too, and the things investors check on a website include whether the company looks like it runs its own house.

A model lab is the far end of this. Chariot's site, which we designed and built, puts its measured latency on the page, set against another system, instead of a word like fast. A company that publishes its speed has to be ready to report it on a slow day. A status page with a Translation speed row is how a smaller product makes the same promise and keeps it.

Where the status link lives

A status page nobody can find during an incident has done half its job. Put the link in four places.

The footer of the website, labelled Status, next to Security and Privacy. Buyers in a review look there first.
Inside the app, in the error itself. When a job runs long, the progress bar should say it is slower than usual and link to the incident. The in-product error states carry the message. The status page carries the record.
The help centre and API docs, at the top of the page, not in a sidebar.
Your saved support reply. One link in the snippet answers every ticket better than a fresh explanation in each.

A status page you can rebuild this week

None of this needs a redesign. It needs an afternoon and a decision to say what you run on.

Monday. List the five jobs customers do most in your product. Make each one a row. Delete Website as a separate row, or fold it into App and sign-in.
Tuesday. Add your model provider as a named row. If your tool supports third-party components, connect it to the provider's page. Add each integration a customer relies on.
Wednesday. Write a speed target for your main job, in plain words, and agree in the team what turns that row yellow.
Thursday. Put the Status link in the footer, the help centre, the docs and the long-running state inside the app.
Friday. Save the write-up template below, so the next incident takes ten minutes to post instead of an afternoon to argue about.

The template has four short parts. Keep each to two sentences.

Title. The job and the cause: Slow translations, model provider returning errors.
What you saw. Translation jobs took up to twenty minutes from 2:30 to 5:10 pm ET. Some uploads failed and needed a retry.
What caused it and what we did. Our model provider had a partial outage, linked here. We moved large files to a backup model at 3:15.
What changes. Slow jobs now switch to the backup on their own, not when we notice. Anything stuck was re-run, and you do not need to upload again.

A status page is a small surface, and it tells a buyer more about your company than most of your homepage does. Studio Maydit is a web and product design studio for AI founders in the US, UK and Europe. We build in Framer, Webflow and custom code, and the same team carries the work into the product, which is where a status message and an in-app error have to agree. Teams heading into enterprise pilots usually take a fixed scope of three to four weeks, and the website design work covers the footer pages buyers check, not just the hero. If your site is telling buyers a smaller story than your product deserves, book a 30 minute call.