How to Add a Status Page to an AI-Built App

A status page is a public page that tells your users whether your app is working right now. When something breaks, it answers the first question every user asks, is it down for everyone or just me, before they email you. For an app built on AI there is a specific twist: a large share of your outages will not be your fault. They will be the model provider having a bad hour. Your status page has to make that clear, or you will take the blame for someone else's downtime.

This guide covers what to monitor, whether to build the page or buy one, and a minimal build you can add to an app you built with AI in an afternoon.

What an AI app actually needs to monitor

A normal web app tracks its own uptime. An AI app depends on a chain of services, and any link can break. Track these separately so you can point at the real cause:

• Your own app: does the site load and can users sign in.

• Your database: can the app read and write.

• The model provider: is the AI API responding, and how fast. This is the one most builders forget, and it is the most common failure.

• Key third parties: payments, email, auth. If checkout is down, users need to know it is checkout, not the whole app.

Separating these matters because your response differs. If your database is down, you fix it. If the model provider is having an outage, there is nothing to fix, and the honest move is to say so on the status page and wait, or fail over to a backup model if you have one.

Build it or buy it

You have two paths. A hosted status page service gives you a polished page, automated checks, and subscriber email alerts, for a monthly fee. A self-built page lives inside your own app, costs nothing extra, and does exactly what you code, no more. Here is the honest trade:

The last row is the real argument for a hosted service. If your status page lives inside the app and the app goes fully down, the status page goes down with it, exactly when users need it. A self-built page is fine for provider and dependency issues, which are more common, but host it separately from the main app if you can.

A minimal status endpoint you can build now

The core of any status page is a health check: a small endpoint that pings each dependency and reports up or down. Start with a JSON endpoint your app already serves:

// GET /api/status  -> checks each dependency, returns JSON
export async function status() {
  const checks = {};
  checks.database = await ping(() => db.query("select 1"));
  checks.model    = await ping(() => aiClient.ping());   // the one that matters
  checks.email    = await ping(() => mailer.verify());
  const allUp = Object.values(checks).every(c => c.ok);
  return { status: allUp ? "operational" : "degraded", checks, time: Date.now() };
}

async function ping(fn) {
  const start = Date.now();
  try { await fn(); return { ok: true, ms: Date.now() - start }; }
  catch (e) { return { ok: false, error: String(e) }; }
}

Then render that JSON on a simple public page with a green or red dot per service and a plain-language summary at the top. Have an uptime checker hit the endpoint every minute from outside your network, so you find out before your users do. If you already added analytics you have most of the plumbing for this.

Write incidents like a human

The page is only half the job. When something breaks, post a short update: what is affected, what you know, and when you will update next. Keep it plain. Users forgive downtime far more readily than silence, a point Atlassian makes well in its guide to incident communication. Pair the status page with a changelog page so people can see both what broke and what you shipped.

A good incident note reads like this:

Degraded performance, 14:10 UTC. AI responses are slow or failing because our model provider is having an outage. Sign-in and your saved data are unaffected. Next update by 14:40 UTC.

Frequently asked questions

Should the status page be public?

Yes, for most apps. A public status page reduces support load and builds trust, because it shows you notice problems and communicate. Keep internal detail like server names off it, but the up or down state should be public.

Where should I host the status page?

Somewhere separate from your main app. If it lives inside the app and the app goes down, so does the page. A hosted status service or a tiny separate deployment solves this. Provider and dependency issues can be reported from inside the app safely, since the app itself is still up.

How often should checks run?

Every minute is a good default for the automated external check. More frequent than that rarely helps and can trip rate limits on the services you are pinging. Keep the check itself lightweight so it does not add load.

What is the single most important thing to monitor?

The model provider's API. It is the dependency you do not control and the one most likely to cause a bad hour, so surfacing its state clearly saves you from being blamed for an outage that is not yours.