Get early access
Features · Discovery & Mapping · Service Discovery
Discovery & Mapping · Service Discovery

No exporters to install.
The list is just there.

The agent walks systemd, opens listening sockets, parses Docker labels and writes the result to your fleet view. New service appears in production at 16:30 — it shows up in HostAtlas before you finish your coffee.

systemd + listening ports
nginx.service :80 :443
php8.3-fpm.service unix socket
postgresql.service :5432
redis-server.service :6379
docker.service :2375 (local)
47 units · no hardcoded list
— Why this matters

A hardcoded list of six services is a list that is wrong.

01

Discovery has to mean all of them.

Every systemd unit is found, not the handful someone thought to enumerate. The list is what the host has, not what we expected.

02

Names should read the way you say them.

php8.4-fpm becomes php-fpm, mariadb becomes mysql. You should not have to know the packaging to find the service.

— What's included

What the agent finds and what you can do with it.

Every systemd unit
Discovered on the host, not matched against a list we shipped.
Listening ports
Read from ss -tlnp and tied to the process holding them.
Noise filtered out
systemd internals, snapd, polkit and similar — present on every box, interesting on none.
Start, stop, restart
From the three-dot menu on the server detail page, audited like everything else.
— How it works

On-host, in seconds.

1

Walk systemd

Talk to systemd-dbus directly. No shelling out to systemctl every minute.

2

Read sockets

A netlink subscription gets the agent an event the moment a port opens or closes.

3

Watch runtimes

Docker / Podman events stream over the runtime socket — no polling.

— Works with

Connected capabilities

Server Auto-Discovery
The parent inventory — services are one of its 12 categories.
→
Service Plugins
When the agent finds MySQL, Postgres, Redis or Nginx, the matching plugin attaches automatically.
→
Auto-Recovery
Per-service restart policies — defined against the services discovered here.
→
Smart Alerts
Build alert rules against unit state without writing PromQL.
→
— FAQ

Questions, answered honestly.

How fast does a newly started service show up? +
Listening sockets within seconds (netlink). systemd units within the next 60 s sync. Containers are immediate via the runtime event API.
Do I need to register services manually anywhere? +
No. If it has a unit file or a listening socket, we see it. You can add a tag to model logical grouping (e.g. tier:edge).
What about ephemeral / cronjob-style invocations? +
systemd timers are surfaced. One-shot processes are not — use Heartbeats for those.

Stop tracking services in a spreadsheet.

Service Discovery is part of every plan.

Get early access Back to Discovery & Mapping