Know the state of your systems: Backstage and Checkmk

This guide connects two sources that tell kanman about the systems your team runs:

• Backstage: your software catalog. kanman learns the components, systems, APIs and resources, who owns them (with the people of each owner group), what they depend on, where their documentation and repository are, and their lifecycle.
• Checkmk: your monitoring. kanman reads the state of hosts and services and their problems, including acknowledgements and planned downtimes.

With them, kanman can:

• answer “How is payment-api doing?” in the chat with a short answer and a card: the health, current problems, recent deploys and merged changes, open incidents, CI, the owner and links to docs, Backstage, the repository and Checkmk
• answer “Who owns payment-api?” and “How are our systems?”
• open incidents from Checkmk problems under your team’s on-call rules, and name the Backstage owner in every new incident

kanman has no dashboard of its own for this: your monitoring stays where it is. kanman speaks up only when it acts on a signal (it opened an incident, filed a fix story or proposed a revert of its own change), and otherwise answers when you ask.

• use the catalog as team context, so questions about a system find its description, owner and dependencies

Owners and admins of the workspace connect the systems; team heads map them to the team. Every member can see them, read them now and ask kanman about the systems.

1. Prepare a token

Backstage: create a token Backstage accepts for its catalog API, for example a static token configured under backend.auth.externalAccess. kanman only reads the catalog.

Checkmk: create an automation user (for example automation) with read access to the hosts and services the team cares about, and copy its automation secret.

2. Connect them

Backstage and Checkmk are connected once for the workspace and then used by every team that maps them.

1. An owner or admin opens Settings › Connections, finds Backstage or Checkmk and connects it:

   • Backstage: the address you open Backstage at, for example https://backstage.example.com, and the token.
   • Checkmk: the site address, for example https://monitoring.example.com/mysite, the automation user as user and its automation secret as secret.

   kanman stores the token or secret as a workspace secret; you find it under Settings › Secrets, where you can replace it later.

2. Click Test connection: kanman checks with a read-only request that it may read the catalog or the monitoring.

3. In the team, open Team › Connections. On the system’s card, add All alerts to read everything, or map only what belongs to the team: for Backstage its owner groups (for example group:default/payments), for Checkmk parts of host names (for example pay-), each to one of your services.

4. kanman reads the system right away and then on its schedule (every six hours for Backstage, every two minutes for Checkmk). The Catalog and monitoring card shows what it found (“142 catalog entries · 23 systems · 6 owners”, “38 hosts · 2 problems”) or why it could not read it; Sync now reads again at once.

Turning the team’s mappings off pauses its reads; the connection stays for the other teams. Sources your team added before connections existed were moved over by kanman with their tokens, filters and what was read.

Systems inside your network

If Backstage or Checkmk is only reachable inside your company network or behind a VPN, choose through your runner when you connect it. Your self-hosted runner then reads the system, also at a plain http:// address, and sends kanman only what it found; kanman’s cloud never connects to it. The runner uses the secret you saved, or a variable of the same name in its environment. In a workspace that runs everything on its runners, every system is read this way. Without a runner online, the card says it waits for one, and kanman reads the system as soon as a runner is back.

3. Connect Checkmk to on-call

Checkmk problems open incidents through the team’s services under Team > Services and on-call (see Services and signal sources). kanman matches a host or service to a service of the team by name: a host payment-api-prod-01 or a service check HTTP payment-api belongs to the service payment-api. A Backstage component can name its hosts exactly with the annotation checkmk.com/hosts: pay-prod-01, pay-prod-02.

The usual on-call rules apply: the severity threshold, on-call hours, who is notified, and what kanman may do (Watch only among them). In addition:

• the first read of a Checkmk site is a baseline: problems that already exist are remembered, not reported, so connecting Checkmk never starts a storm of incidents
• problems that have been open for a day or longer are part of the normal and never page anyone, however many there are
• acknowledged problems and problems in a planned downtime never open an incident
• related problems of one service join one incident; at most 20 new problems are reported per read
• a problem that is OK again resolves its part of the incident; when nothing fires any more, the incident is resolved
• severities: host down is critical, unreachable and CRIT are high, WARN is medium, UNKNOWN is low
• hosts that match no service are recorded but open no incident

Every new incident names the service’s owner from Backstage and its people, so the person on call knows whom to pull in.

kanman only reads Checkmk: it never acknowledges a problem or schedules a downtime. If your company only allows production signals through its own MCP servers, choose Through your MCP server when you add the source. Metrics from Prometheus, Grafana and InfluxDB work the same way: see Monitoring signals.

4. Ask kanman

In the team’s chat (or in General, where kanman looks through all your teams), ask:

• “How is payment-api doing?” or “Wie läuft payment-api?”
• “Who owns payment-api?”
• “How are our systems?” or “What is down?”

kanman answers in a few sentences and attaches the system’s card. It says when monitoring was last read and never guesses a cause the facts do not show. In a workspace that runs everything on its runners, the answer is worded by your runner’s model.

When kanman opens an incident, its message in the team’s chat carries How is it doing?: one tap asks kanman about the service and brings up the same card. The fix story kanman files and a revert proposal arrive as replies under that message.

Developers get the same facts in their coding agent through the kanman MCP tool service_status.