Skip to content
AlertKick AlertKick AlertKick Docs

Services and topology

A service is the thing your customers or colleagues actually use: the checkout API, the internal wiki, the nightly reporting batch. In AlertKick a service is a named group of the hosts, containers, and monitors behind it, plus the facts that matter during an incident - how critical it is, what it depends on, who owns it, and where the runbook is. Services live under Status, then Services.

Services do three jobs:

  • Triage context. When an alert fires on a host or monitor, Kicker looks up which services it belongs to and how many other services depend on them. Criticality plus that blast radius sets how urgently the alert is treated. See AI triage and Kicker.
  • Status pages. A status-page component can reference a service, and its customer-facing state is rolled up from the service’s monitors. See Public status pages.
  • Incidents. The affected-services picker on an incident is this list. See Incidents.

Create a service

Section titled “Create a service”

Status, then Services, then Add Service.

FieldNotes
NameRequired, up to 120 characters
DescriptionFree text
Tier1 revenue or customer-facing, 2 supporting, 3 internal or batch. 0 means unset.
Service URLMust start with http:// or https://. If a monitor already checks this URL the detail page links it; if not, you can create one from there.
HostsServers running the agent
MonitorsUptime, SSL, DNS, TCP, domain, or mail monitors
Depends onOther services this one needs. A service cannot depend on itself.
Runbook URLLinked from the detail page and shown to Kicker during triage
Owner teamFree text

Each linked list holds up to 100 entries. A monitor can belong to only one live service; linking it to a second returns “A linked monitor already belongs to service X”. Hosts can be shared.

The service record is the only place the edges are stored. Hosts and monitors do not know which services they belong to, so deleting a service removes the grouping and nothing else.

Proposed by Kicker

Section titled “Proposed by Kicker”

Once a day Kicker builds topology proposals from what the agent reports: Docker Compose projects, listening ports, container port maps, and which monitors point at which hosts. The derivation is deterministic - no model is involved - and every proposal arrives inactive, in a Proposed by Kicker card at the top of the services list, with the evidence it was built from and two buttons: Confirm and Reject.

Confirming creates a live service you can edit like any other; the detail page shows a “Kicker proposed” label and who confirmed it. Rejecting discards the proposal, and Kicker does not re-propose the same shape. Until confirmed, a proposal is not a service: it does not appear on status pages or in the incident picker.

The service page

Section titled “The service page”

Open a service to see:

  • Header with the tier, a “Manual” or “Kicker proposed” label, and Edit and Delete.
  • URL row showing “Monitored by” and the monitor that checks the service URL, or a Link monitor / Add monitor for this URL action when nothing does.
  • Topology, a graph laid out left to right: the URL, the monitors checking it, the service, its hosts, the containers on those hosts, and the services it depends on. Nodes are clickable and deep-link to the monitor, host, or service. Container nodes carry live state from the agent.
  • Hosts & containers with each host’s containers and their current state.
  • Monitors linking to each monitor’s page.
  • Details: dependencies, owner team, runbook, who created and who confirmed it.

How a service’s status is computed

Section titled “How a service’s status is computed”

There is no hand-set status. Where a service’s state is shown to customers - on a status page - it is rolled up from the linked monitors at render time: any monitor in a failing state degrades the component, and paused, pending, or disabled monitors contribute nothing. Inside the dashboard the topology graph colours container nodes from live agent state; hosts and monitors show their own status on their own pages.

Tips

Section titled “Tips”
  • Give every customer-facing service a tier of 1 and a runbook URL first. Those two fields are what change Kicker’s behaviour most.
  • Model dependencies in the direction traffic flows: checkout depends on payments-db, not the other way round. Blast radius counts the services that depend on the one that broke.
  • Let Kicker propose before you type. A day after installing agents on a Compose host, the proposals usually match what you would have entered.

Next steps

Section titled “Next steps”