Prometheus + Grafana Monitoring on UK VPS: Metrics & Alerting Setup Guide 2026

Prometheus and Grafana are the de facto open-source stack for serious server monitoring, giving you full time-series metrics, rich dashboards and proactive alerting in one self-hosted package. If simple uptime checks tell you whether a service is up, this stack tells you how it is performing over time and warns you before things break. This guide walks UK sysadmins, DevOps engineers and agencies through installing and configuring the whole stack on a UK VPS in 2026.

What Are Prometheus and Grafana?

Prometheus is an open-source time-series database and monitoring system. It works on a pull model: at fixed intervals it scrapes metrics from HTTP endpoints (called targets), stores them efficiently, and lets you query them with its own query language, PromQL. Because it collects numeric time-series data rather than just pinging a URL, it can tell you CPU load, memory pressure, request latency and hundreds of other signals over time.

Grafana is the visualisation layer. It is an open-source dashboarding tool that queries Prometheus (and dozens of other data sources) to render graphs, panels and full Grafana dashboards. You point Grafana at Prometheus, build or import a dashboard, and suddenly your raw time-series metrics become readable charts. Grafana also has its own alerting engine, though many teams keep alerting inside the Prometheus ecosystem with Alertmanager.

Together these tools form a complete observability stack. This is a clear step up from lightweight uptime monitoring: where a tool like Uptime Kuma answers “is it up?”, Prometheus and Grafana answer “how is it performing, and where is it heading?”. The two approaches are complementary rather than competing.

Why Self-Host Your Monitoring Stack

Hosted observability platforms are convenient, but they bill per metric, per host or per GB ingested, and those costs climb fast as you add servers. Self-hosting on a VPS you already control flips the economics: a single small instance can monitor a fleet of machines for the price of the box. You also keep full ownership of your telemetry, which matters when metrics contain hostnames, IP addresses and traffic patterns you would rather not hand to a third party.

Data residency is another driver. Running the stack on a UK VPS keeps your monitoring data physically in the UK, which simplifies compliance conversations and keeps latency low when scraping other UK-based servers. A UK Speed VPS gives you the persistent storage and predictable resources this kind of always-on workload needs, without the metered surprises of a SaaS bill.

What You Need for Prometheus and Grafana

The requirements are modest. To run the stack comfortably for a handful of hosts you will want:

• A UK VPS with at least 2 GB RAM and 2 vCPUs (more if you retain long histories or scrape many targets).
• Docker and Docker Compose installed, so the whole stack runs as containers.
• A domain or subdomain plus a reverse proxy for secure HTTPS access.
• Basic familiarity with the Linux command line and, ideally, systemd services for anything you run outside containers.

How Prometheus and Grafana Work Together

Understanding the data flow makes the configuration far easier. Each component has a single clear job, and they connect over HTTP on well-known ports.

The loop looks like this: node_exporter (and any other exporters) expose metrics on an HTTP endpoint. Prometheus scrapes those endpoints every 15 seconds or so and stores the results. Grafana queries Prometheus with PromQL to draw dashboards. When a metric crosses a threshold you have defined, Prometheus fires an alert to Alertmanager, which decides who gets notified and how. This pull-based, exporter-driven design is what separates a true observability stack from a basic ping test.

How to Install the Stack with Docker

Docker Compose is the cleanest way to deploy the whole stack because every component becomes a container on a shared network, and containers can reach each other by service name. If you are new to Compose, our Docker Compose on UK VPS guide covers the fundamentals. For the full reference on every flag and setting, keep the official Prometheus documentation open alongside this walkthrough.

Start with a docker-compose.yml that defines Prometheus, Grafana and node_exporter on one network:

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=change_me_now
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"

  node-exporter:
    image: prom/node-exporter:latest
    ports:
      - "9100:9100"

volumes:
  prom_data:
  grafana_data:

Next create prometheus.yml to tell Prometheus what to scrape. Notice that the target is referenced by its Compose service name, node-exporter, not an IP address:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

Bring the stack up with docker compose up -d. Prometheus will be live on port 9090 and Grafana on port 3000. Log in to Grafana with the admin password you set, then add Prometheus as a data source using the internal URL http://prometheus:9090 so Grafana talks to it over the Docker network.

How to Add node_exporter and Targets

The node_exporter container in the Compose file already exposes host metrics such as CPU usage, memory, disk space, filesystem and network throughput on port 9100. To confirm Prometheus is collecting them, open the Prometheus web UI, go to Status then Targets, and check the node job shows as UP. If it does, you now have real time-series metrics flowing.

To monitor additional servers, install node_exporter on each one and add them as targets. To monitor other layers of your stack, add more exporters. Each exporter translates a system’s internal state into Prometheus-friendly metrics:

Adding a target is simply a matter of extending scrape_configs with a new job and reloading Prometheus. Combined with reading your server logs, exporters give you both the numbers and the narrative behind an incident.

Build Dashboards in Grafana

You do not have to build Grafana dashboards from scratch. The community publishes thousands of ready-made dashboards, and the single most useful one for a new stack is Node Exporter Full, dashboard ID 1860. In Grafana go to Dashboards, choose Import, paste 1860, and select your Prometheus data source. Within seconds you get a comprehensive view of every host metric node_exporter provides.

When you are ready to build your own panels, PromQL is the language you will use. A few examples that map cleanly onto Grafana panels:

# CPU usage percentage per instance
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Available memory in bytes
node_memory_MemAvailable_bytes

# Root filesystem usage percentage
100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100)

Good dashboards focus on the signals that predict trouble: CPU saturation, memory headroom, disk fill rate and request latency. If you are tuning application performance, pairing these dashboards with our sub-100ms TTFB guide helps you connect infrastructure metrics to real user experience.

Configure Alerting with Alertmanager

Dashboards are useful when you are looking at them, but alerting is what protects you at 3am. In the Prometheus ecosystem, Prometheus evaluates alert rules and Alertmanager handles routing and delivery. Add Alertmanager as another service in your Compose file, exposing port 9093, then define your rules.

Alert rules live in a rules file that Prometheus loads. Here is a compact example covering an unreachable instance, high CPU and low disk:

groups:
  - name: host-alerts
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} is down"

      - alert: HighCPU
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 10m
        labels:
          severity: warning

Alertmanager then decides where those alerts go. Its configuration defines receivers, and you can route different severities to different channels. Common receivers include email (SMTP), Slack via an incoming webhook, and Telegram via a bot token and chat ID. A minimal Slack receiver looks like this:

route:
  receiver: 'team-slack'

receivers:
  - name: 'team-slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'
        channel: '#alerts'
        title: '{{ .CommonAnnotations.summary }}'

With this in place, an up == 0 that persists for two minutes lands in your Slack channel automatically. This is the “alert me before it fails” capability that lightweight uptime monitoring tools only partially provide.

Best Practices for Production Monitoring

A monitoring stack is only trustworthy if it is secure and correctly tuned. The most common mistake is leaving Prometheus and Grafana exposed to the public internet without authentication.

• Never expose the UIs unauthenticated. Put Grafana and Prometheus behind a reverse proxy with HTTPS and authentication, or restrict access to a VPN. Ports 9090 and 3000 should not be open to the world.
• Change the default Grafana password immediately, and disable anonymous access.
• Set sensible retention. Use --storage.tsdb.retention.time to cap how long metrics are kept (30 days is a reasonable start) so disk usage stays predictable.
• Watch the watcher. Alert on the monitoring host itself; if Prometheus runs out of disk, you lose visibility exactly when you need it.
• Back up Grafana dashboards and the Prometheus data volume, and keep your configuration in version control.

Treat the whole stack as production infrastructure: keep the containers updated, review your alert rules periodically so they neither cry wolf nor stay silent, and document what each alert means for whoever is on call.

Conclusion

Prometheus and Grafana turn a UK VPS into a powerful, self-owned observability platform. Prometheus collects and stores your time-series metrics, node_exporter feeds it host data, Grafana makes it readable, and Alertmanager makes sure you hear about problems before your users do. It is heavier than a simple uptime check, but it answers questions uptime tools never can.

Once the stack is running, keep improving it rather than leaving it static.

• Deploy the Docker Compose stack on a UK VPS and confirm node_exporter targets are UP.
• Import dashboard 1860 and build one custom panel with PromQL.
• Add Alertmanager and wire up your first alert to Slack, email or Telegram.
• Secure both UIs behind HTTPS and set a retention policy before going live.