Components

A component is a part of your service you report on separately — API, Web app, Database, Email delivery. Each has its own state, and those states add up to the overall status at the top of the page.

Cut them the way your customers experience your service, not the way your infrastructure is built. "Checkout" tells a customer more than "payment worker pool 3".

The five states

State Meaning
Operational Normal.
Degraded performance Working, but slow or unreliable.
Partial outage Part of it is down, part of it is not.
Major outage Not usable.
Maintenance Planned work in progress.

The page's overall status is always the worst state among visible components. One component in major outage turns the whole page red — deliberately, because that is exactly what an affected customer is experiencing.

The states affect uptime differently; see Uptime.

What you configure per component

  • Name — what the customer reads.
  • Description — one line underneath, optional. Good for scope: "includes the webhooks".
  • Group — optional, see below.
  • Current status — settable directly, without opening an incident. For short things there is nothing to narrate about.
  • Position — the order on the page. Lower number, higher up.
  • Show uptime — hides the bars for this component only. Useful for something you only started tracking yesterday.
  • Uptime start date — when the calculation begins. Before it the bars stay empty instead of claiming 100% where nothing was measured.
  • Visible — takes the component off the public page without deleting it. It then no longer counts towards the overall status either.

Groups

Past a handful of components the list stops being readable. Groups collect what belongs together — Core platform, Integrations, Regions.

Per group you set:

  • Name and description
  • Position in the list
  • Collapsed by default — the group starts closed. Useful for long lists where most visitors only want to know whether the top is green.
  • Visible — as for components.

A component without a group sits above the groups, not below them. The important thing stays at the top even when the rest is organised.

The same component in several groups: when you create a component you can pick several groups. Each one gets a component of its own with its own status, for example Server in eu01 and in eu02. If the server in eu01 goes down, eu02 stays green. Each counts separately towards your plan's component limit. Afterwards you edit them one by one. Through the API you create them with one call per group.

Groups are available from the Basic plan.

How a state changes

Six ways, and all of them land in the audit log:

  1. By hand in the dashboard, on the component itself.
  2. Through an incident — affected components take the state the severity implies. Resolving the incident returns them to operational, unless another open incident still holds them.
  3. Through a maintenance — with Update component status on, affected components go to Maintenance for the duration.
  4. Through an HTTP check — if it may switch the component, it sets it itself on a confirmed outage.
  5. Through the API — POST /api/v1/components/{id}/status, see below.
  6. Through an AI assistant — with the set-component-status tool of the MCP server.

Through the API

curl -X POST https://statuswerk.eu/api/v1/components \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "API", "description": "REST interface", "visible": true}'

# Set the status only
curl -X POST https://statuswerk.eu/api/v1/components/{id}/status \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -d '{"status": "degraded_performance"}'

Full detail in the API reference.