Skip to content

What do you need to do?

Docs

Monitor Docker containers with RealUptime

The Monitor agent ships as a Docker image on purpose: one line adds it to any Compose file you already run. It reports the container's own CPU, memory, and disk, and, on agents from version 0.2, the other containers on the same host from cgroup v2 without a second agent per container.

On this page

What you are setting up

The agent as one more service in your Docker Compose stack (or a standalone docker run), a check for each service your containers expose publicly, and a status page. For why restart policies and HEALTHCHECK directives are not monitoring, see the knowledge-base how-to Monitor Docker containers from outside the host.

Install the agent

Register an agent from Monitor settings in the dashboard first; the token is shown once, with the exact command already filled in. Standalone:

docker run -d --name realuptime-agent --restart unless-stopped --network host -e REALUPTIME_TOKEN=rua_your_token_here ghcr.io/realuptimehq/agent:latest

Or as a service alongside the rest of your stack:

services:
  app:
    image: myorg/myapp:latest
    restart: unless-stopped
    ports:
      - "8080:8080"

  realuptime-agent:
    image: ghcr.io/realuptimehq/agent:latest
    restart: unless-stopped
    network_mode: host
    environment:
      REALUPTIME_TOKEN: rua_your_token_here

Both carry host networking on purpose. An agent watching its own host has to share that host's network, or localhost means the container and every check against a host-local service is refused while the service is healthy.

On a host with a package manager and no Docker preference either way, the same one-liner works and picks Docker automatically when it is present:

bash
curl -fsSL https://realuptime.io/agent/install.sh | REALUPTIME_TOKEN=rua_your_token_here sh

See Monitor agent, "If you run it inside a container", for the host-networking note: running the agent in its own isolated container reports that container's own limits, not the host's, which is correct and expected, not a bug to work around unless your goal is specifically the host's own numbers.

Create the checks

One HTTP or TCP check per container that exposes a port publicly. This is a check of reachability from outside, run by the cloud probe fleet, separate from the agent, which only reports the host's and containers' own resource usage:

bash
export REALUPTIME_API_KEY=ru_live_...

realuptime checks create \
  --name "app container" \
  --url http://your-host:8080/ \
  --interval 60 \
  --regions iad,fra

Add a status page

Create a status page and add both the agent's host component and your container checks, so "the host is fine, one container is down" and "the host itself is in trouble" read as different incidents. See Status pages.

What RealUptime does and does not see

The agent reads host and container resource usage from cgroup v2 and /proc; it opens no inbound port, runs no command RealUptime sends, and reads no container's logs, environment variables, or files. See Monitor agent, "Outbound only", for the exact guarantee.

HTTP and TCP checks see reachability and response from outside the host, exactly like any other client. Neither the agent nor a check reads a container's image, its build, or a registry it was pulled from; that stays entirely yours.