Página de estado

Loop includes a /status page with demo uptime data so you can see the design immediately. Swap the data source for BetterStack, Statuspage, or your own monitor when you go live.

What ships by default

The status page renders from siteConfig.statusServices and siteConfig.statusIncidents. Services show a 60-day uptime bar; incidents show a timeline with severity and resolution status.

statusServices: [
  { id: "api", name: "API", history: [/* 60 daily values */], uptime: 99.98 },
  { id: "slack", name: "Slack integration", history: [/* … */], uptime: 99.97 },
]

Each history entry is 1 (operational), 0.5 (degraded), or 0 (outage). The demo data is generated deterministically so the page looks alive without a backend.

Option A — BetterStack

BetterStack exposes a status API you can poll on the server:

export async function getStatus() {
  const res = await fetch("https://uptime.betterstack.com/api/v2/monitors", {
    headers: { Authorization: `Bearer ${process.env.BETTERSTACK_TOKEN}` },
    next: { revalidate: 60 },
  });
  return toServices(await res.json());
}

Map their monitor responses onto the StatusService shape and the page renders unchanged.

Option B — Statuspage / Instatus

Both provide a public JSON summary endpoint. Fetch it server-side and translate components and incidents into Loop's StatusService and StatusIncident interfaces.

Option C — Your own monitor

If you run your own health checks, write the 60-day history array yourself from your metrics store. The bar visualization only needs that array plus an uptime percentage.

Removing the status page

If you don't want a public status page, delete the /status route and remove the statusServices and statusIncidents arrays from config. The footer link to it can be dropped at the same time.