Gatus

Search the Azure Marketplace for Gatus, choose the plan and create the VM.

In the networking step, attach a network security group. Allow inbound TCP 22 (SSH) from your management address. Allow TCP 443 (the dashboard) and TCP 80 (redirect only) from the people who need the status page.

RG="gatus-prod"; LOCATION="eastus"; VM_NAME="gatus-01" IMAGE_URN="sac1647283583153:gatus-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name gt-vnet --address-prefix 10.106.0.0/16 --subnet-name gt-subnet --subnet-prefix 10.106.1.0/24 az network nsg create -g "$RG" --name gt-nsg az network nsg rule create -g "$RG" --nsg-name gt-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name gt-nsg --name allow-web --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 80 443 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:gatus-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name gt-vnet --subnet gt-subnet --nsg gt-nsg --public-ip-sku Standard

Connect as the admin user you chose (here azureuser):

ssh azureuser@<vm-ip>

First boot finishes within a minute of the VM starting. It reads the VM's public IP address from the Azure Instance Metadata Service, creates the HTTPS certificate, generates the password and starts nginx. Then Gatus starts its checks. Your login is in a root-only file:

sudo cat /root/gatus-credentials.txt

# Gatus - generated on first boot by gatus-firstboot.service
# These credentials are unique to this VM. Store them somewhere safe. GATUS_URL=https://20.121.0.141/ GATUS_USERNAME=admin GATUS_PASSWORD=<GATUS_PASSWORD>
#
# Open GATUS_URL in a browser (self-signed certificate minted on this VM's first boot; port 80 # redirects to https) and sign in with the username and password above. The same credentials protect # the JSON API (/api/v1/endpoints/statuses) and the status badges. # Change the name it is served as:
sudo gatus-set-hostname <your-dns-name>
#
# The default endpoints monitor this VM only. Add your own services to /etc/gatus/config.yaml
# (Gatus reloads it automatically). Restrict 80/443 in the network security group to the people who need the page.
# Full deployment guide: https://secureanycloud.com/stacks/gatus/

GATUS_URL holds your VM's public IP address and GATUS_PASSWORD your VM's own password.

Check that first boot, Gatus and nginx are active, that Gatus runs as the unprivileged gatus user, and that the open health endpoint answers:

systemctl is-active gatus-firstboot.service gatus.service nginx.service ps -o user= -C gatus test "$(curl -sk https://localhost/healthz)" = ok && echo "healthz ok"

active active active gatus healthz ok

nginx serves /healthz without a login, so you can use it for an Azure Load Balancer or Application Gateway health probe over HTTPS. Everything else needs the password.

List the ports the VM listens on. These are the only ones:

sudo ss -Hltnu | awk '{print $1, $5}' | sort -u

tcp 0.0.0.0:22 tcp 0.0.0.0:443 tcp 0.0.0.0:80 tcp 127.0.0.1:8080 tcp 127.0.0.53%lo:53 tcp 127.0.0.54:53 tcp [::]:22 tcp [::]:443 tcp [::]:80 udp 10.0.0.10%eth0:68 udp 127.0.0.1:323 udp 127.0.0.53%lo:53 udp 127.0.0.54:53 udp [::1]:323

Gatus (8080) listens on loopback only, and nginx publishes it on 443. The loopback port 53 entries are Ubuntu's local stub resolver (systemd-resolved), 323 is chrony's local control socket and 68 is the DHCP client.

The binary is the reproducible SecureAnyCloud build of the 5.36.0 source. Its record ships with the image. Check it:

sha256sum /usr/local/bin/gatus grep -E '^(source|toolchain |binary|govulncheck)' /usr/share/doc/gatus/BUILD-INFO.txt

07676fb59df06f69deb9d1c155c21eff7da6d0bb4e32585ed82d06cc7f982a66 /usr/local/bin/gatus source https://github.com/TwiN/gatus/archive/refs/tags/v5.36.0.tar.gz source sha256 b5543af591e602281406049ee2f822a6529a8f14be0cd54df5a31c210520159a (tag commit ed1107b41a30e22047eecfb6dbc3be5e39829d5a) toolchain go1.27.3 linux/amd64, official tarball https://go.dev/dl/go1.27.3.linux-amd64.tar.gz toolchain sha256 65efbc80fdc1fa2cd2631cad5b481777a68e8725f34e89f50fc6ac714e379b40 binary sha256 07676fb59df06f69deb9d1c155c21eff7da6d0bb4e32585ed82d06cc7f982a66 (reproducible) govulncheck v1.9.0 -mode=binary and source mode: only GO-2026-5932 (DB updated: 2026-10-21 00:27:29 +0000 UTC)

Browse to the GATUS_URL from Step 3, for example https://20.121.0.141/. The certificate is self-signed, so your browser warns once. Accept it, or install your own certificate (Step 9). Without a login, nginx answers 401 and your browser asks for a username and password:

Sign in as admin with the password from Step 3. The Gatus health dashboard lists the three starter endpoints, each with its latest result and a bar per check:

Select an endpoint to open its detail page. It shows the current status, the average and range of response times, the recent checks and a response-time chart:

Port 80 only redirects to the HTTPS address. A request for any host name that is not this VM's is dropped without an answer (000):

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://localhost/
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: not-this-vm.example' http://127.0.0.1/ || true

301 https://20.121.0.141/ 000

You can also check the login from the command line. These requests go to nginx on the VM itself. The API refuses a request with no password or a wrong one. The VM's own password returns the endpoint statuses. The block reads the password from the credentials file and passes it to curl on standard input, never on the command line. It stops with an error if any answer is not the expected one:

H=$(sudo sed -n 's/^set $gatus_host "\(.*\)";$/\1/p' /etc/nginx/gatus-host.conf) AUTH() {
sudo sed -n 's/^GATUS_PASSWORD=\(.*\)$/user = "admin:\1"/p' /root/gatus-credentials.txt; }
U=$(curl -sk --resolve "$H:443:127.0.0.1" -o /dev/null -w '%{http_code}' "https://$H/api/v1/endpoints/statuses")
W=$(printf 'user = "admin:not-the-password"\n' | curl -K - -sk --resolve "$H:443:127.0.0.1" -o /dev/null -w '%{http_code}' "https://$H/api/v1/endpoints/statuses")
A=$(AUTH | curl -K - -sk --resolve "$H:443:127.0.0.1" -o /dev/null -w '%{http_code}' "https://$H/api/v1/endpoints/statuses")
echo "unauth : $U";
echo "wrongpw : $W";
echo "authed : $A" [ "$U" = 401 ] && [ "$W" = 401 ] && [ "$A" = 200 ]

unauth : 401 wrongpw : 401 authed : 200

The dashboard is built on a JSON API that you can use from scripts. This block lists every endpoint with how many results Gatus holds and whether the latest check passed. It fails unless all three starter endpoints are healthy:

H=$(sudo sed -n 's/^set $gatus_host "\(.*\)";$/\1/p' /etc/nginx/gatus-host.conf) AUTH() {
sudo sed -n 's/^GATUS_PASSWORD=\(.*\)$/user = "admin:\1"/p' /root/gatus-credentials.txt; }
J=$(AUTH | curl -K - -sk --resolve "$H:443:127.0.0.1" "https://$H/api/v1/endpoints/statuses")
echo "$J" | jq -r '.[] | "\(.key) results=\(.results|length) last_success=\(.results[-1].success)"' test "$(echo "$J" | jq -r '[.[] | select(.results[-1].success == true) | .name] | sort | join(",")')" = "gatus,nginx-https,ssh"

this-instance_gatus results=5 last_success=true this-instance_nginx-https results=5 last_success=true this-instance_ssh results=5 last_success=true

Each endpoint's key is <group>_<name>. The detail of one check shows each condition and its result:

H=$(sudo sed -n 's/^set $gatus_host "\(.*\)";$/\1/p' /etc/nginx/gatus-host.conf) AUTH() {
sudo sed -n 's/^GATUS_PASSWORD=\(.*\)$/user = "admin:\1"/p' /root/gatus-credentials.txt; } AUTH | curl -K - -sk --resolve "$H:443:127.0.0.1" "https://$H/api/v1/endpoints/this-instance_nginx-https/statuses" \
  | jq -e '.results[-1] | {status, success, conditionResults}'

{ "status": 200, "success": true, "conditionResults": [ { "condition": "[STATUS] == 200", "success": true }, { "condition": "[BODY] == pat(ok*)", "success": true }, { "condition": "[CERTIFICATE_EXPIRATION] > 720h", "success": true } ] }

Status badges live under the same API, for example https://<your-host>/api/v1/endpoints/this-instance_ssh/health/badge.svg, and they also need the password.

The configuration is /etc/gatus/config.yaml. Only root and the gatus service account can read it, because the alerting tokens you add will live there. This is the starter file:

sudo stat -c '%a %U:%G %n' /etc/gatus/config.yaml
sudo grep -vE '^\s*#|^$' /etc/gatus/config.yaml

640 root:gatus /etc/gatus/config.yaml storage: type: sqlite path: /var/lib/gatus/data.db web: address: 127.0.0.1 port: 8080 metrics: false ui: title: "Status | Gatus" header: "Service Health" description: "Live health and uptime of the services monitored by this instance." endpoints: - name: nginx-https group: this-instance url: "https://127.0.0.1/healthz" interval: 60s client: insecure: true conditions: - "[STATUS] == 200" - "[BODY] == pat(ok*)" - "[CERTIFICATE_EXPIRATION] > 720h" - name: gatus group: this-instance url: "http://127.0.0.1:8080/health" interval: 60s conditions: - "[STATUS] == 200" - "[BODY].status == UP" - name: ssh group: this-instance url: "tcp://127.0.0.1:22" interval: 60s conditions: - "[CONNECTED] == true"

Edit it with sudoedit (or your editor of choice through sudo) and append your services under endpoints:. This example adds a website with a response-time and certificate check, a database port, and a DNS record:

sudoedit /etc/gatus/config.yaml

- name: website group: production url: "https://www.example.com/" interval: 60s conditions: - "[STATUS] == 200" - "[RESPONSE_TIME] < 800" - "[CERTIFICATE_EXPIRATION] > 336h" - name: postgres group: production url: "tcp://10.0.1.20:5432" interval: 30s conditions: - "[CONNECTED] == true" - name: dns-www group: production url: "1.1.1.1" dns: query-name: "www.example.com" query-type: "A" conditions: - "[DNS_RCODE] == NOERROR"

Gatus checks the file for changes every 30 seconds and reloads it on its own. You do not need to restart it.

If an edit does not parse, Gatus logs the error and exits. systemd keeps restarting it every few seconds, so the dashboard is down until you correct the file. It then comes back by itself. Check the service and the log after each change:

systemctl is-active gatus
sudo journalctl -u gatus -n 20 --no-pager -o cat

To be notified when a check fails, add an alerting: block (for example Slack, email or PagerDuty) and an alerts: list on each endpoint. The Gatus alerting documentation has an example for every provider. Keep the file 0640 root:gatus.

The Gatus log shows each check as it runs:

sudo journalctl -u gatus -n 3 --no-pager -o cat | grep -E 'success=(true|false)'

2026/10/21 16:08:29 [watchdog.executeEndpoint] Monitored group=this-instance; endpoint=nginx-https; key=this-instance_nginx-https; success=true; errors=0; duration=4ms 2026/10/21 16:08:29 [watchdog.executeEndpoint] Monitored group=this-instance; endpoint=gatus; key=this-instance_gatus; success=true; errors=0; duration=1ms 2026/10/21 16:08:29 [watchdog.executeEndpoint] Monitored group=this-instance; endpoint=ssh; key=this-instance_ssh; success=true; errors=0; duration=0s

Gatus checks run from this VM, so Gatus can watch services that are not on the internet at all. Examples are databases, internal APIs and load balancers in the same virtual network or in peered networks. Make sure the network security groups of those services allow traffic from this VM.

ICMP (icmp://) checks work too, without giving Gatus any capability. The image allows unprivileged ICMP sockets for the gatus group only (/etc/sysctl.d/60-sac-gatus-ping.conf).

The certificate was created on your VM's first boot for the VM's public IP address, its private IP address and localhost. Only root can read the key and the credentials file. The password hash is readable by root and nginx's group:

sudo openssl x509 -in /etc/ssl/gatus/gatus.crt -noout -subject -dates -ext subjectAltName
sudo stat -c '%a %U:%G %n' /etc/ssl/gatus/gatus.key /etc/ssl/gatus/gatus.crt /etc/nginx/.gatus.htpasswd /root/gatus-credentials.txt

subject=CN = 20.121.0.141, O = sac notBefore=Oct 21 16:07:30 2026 GMT notAfter=Jan 23 16:07:30 2029 GMT X509v3 Subject Alternative Name: IP Address:20.121.0.141, IP Address:10.0.0.10, IP Address:127.0.0.1, DNS:localhost 600 root:root /etc/ssl/gatus/gatus.key 644 root:root /etc/ssl/gatus/gatus.crt 640 root:www-data /etc/nginx/.gatus.htpasswd 600 root:root /root/gatus-credentials.txt

To serve the dashboard under your own DNS name, point the name at this VM and run the helper. The name can be, for example, status.example.com, or the DNS name label of the VM's public IP such as gatus-01.eastus.cloudapp.azure.com. The helper records the name, creates a new self-signed certificate for it, updates nginx and rewrites the URL in the credentials file:

sudo gatus-set-hostname status.example.com

If the VM's public IP address changes (for example a dynamic address after a deallocation), run the helper again so that the certificate names the new address too.

To use a certificate from your own certificate authority, replace /etc/ssl/gatus/gatus.key (keep it 0600 root) and /etc/ssl/gatus/gatus.crt. Then run sudo systemctl reload nginx.

gatus.service and nginx.service carry a systemd IPAddressDeny rule for the Azure Instance Metadata Service and the Azure wire server. No check can reach them, even if an endpoint's URL points at one. First boot, which reads the public IP address, runs outside both services. DNS names still resolve for your checks, because Gatus asks Ubuntu's local resolver (127.0.0.53), which forwards on its own:

systemctl show -p IPAddressDeny gatus.service nginx.service

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 168.63.129.16/32

A Gatus dns endpoint that names 168.63.129.16 as its server is blocked by the same rule. Use another resolver address in such checks.

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Gatus. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Gatus is very light, but m5.large is the tested recommendation. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet. Then create or select a security group that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks your users use. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes under a minute after the instance state becomes Running and the status checks pass.

The following block launches an instance from the SecureAnyCloud Gatus Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing and <key-name> with your EC2 key pair name. Replace <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22, 80 and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options "HttpTokens=required,HttpEndpoint=enabled" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=gatus}]'

On first boot, the image resolves this instance's public address using the EC2 Instance Metadata Service (IMDSv2), so it works with HttpTokens=required enabled.

Connect as the ubuntu user:

ssh ubuntu@<public-ip>

As soon as you log in, the message of the day prints the dashboard URL, the status API URL and the key operational commands.

Gatus has no login and no credential to retrieve. For convenience, the first boot service writes a root-only note with the resolved dashboard URL:

sudo cat /root/gatus-info.txt

Gatus and nginx start automatically. Confirm that both are active:

systemctl is-active gatus nginx

Browse to http://<public-ip>/ to see the live status page. It refreshes automatically and shows each configured endpoint with its current health, recent checks and average response time.

The dashboard is read-only and has no login, so it is safe to publish as a status page. Still, restrict who can reach it if the endpoint names or URLs are sensitive.

Verify that the dashboard is answering. Run this from the instance itself, through nginx:

for i in $(seq 1 30); do code=$(curl -s -o /dev/null -w '%{http_code}' -m 5 http://127.0.0.1/) [ "$code" = "200" ] && break sleep 2 done echo "dashboard HTTP $code"

Each endpoint links to a detail view with its current status, average response time, response-time range, recent check history and a response-time trend chart.

The dashboard also has a built-in dark mode.

The same results are available as JSON. Use the API for scripting and for wiring Gatus into your own tooling:

curl -s http://127.0.0.1/api/v1/endpoints/statuses | jq '[.[] | {name, group, healthy: ([.results[]?|select(.success==true)]|length>0)}]'

The whole configuration lives in one declarative YAML file. Add or edit the services you want to watch under endpoints:, then restart Gatus to apply the change. Each endpoint has a url, an interval, and one or more conditions such as [STATUS] == 200, [RESPONSE_TIME] < 300, or [CERTIFICATE_EXPIRATION] > 240h.

sudo nano /etc/gatus/config.yaml
sudo systemctl restart gatus

The default configuration monitors this instance's own web server (an always available local nginx health target) plus two well known public endpoints, including a TLS certificate expiry check. The dashboard is populated the moment the instance boots. Replace those examples with your own services.

The dashboard ships open and read-only by design. To require a viewer password, use Gatus' HTTP basic authentication. Install apache2-utils for the htpasswd tool, generate a bcrypt hash on this instance, and add a security.basic block to the configuration. Never bake a hash into an image, and do not reuse a hash across instances.

# Install the htpasswd tool, then generate a bcrypt hash for your chosen
# password on THIS instance (replace <viewer-password> with your own):
sudo apt-get install -y apache2-utils htpasswd -bnBC 10 "" "<viewer-password>" | tr -d ':\n'

Add the resulting hash under a security block in /etc/gatus/config.yaml (see the Gatus documentation for the exact security.basic schema), then restart Gatus with sudo systemctl restart gatus.

For production, terminate TLS at nginx. Point a DNS record at the instance, open port 443, and obtain a certificate with certbot. Replace <your-domain> with your host name.

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

certbot installs and renews the certificate, and it updates the nginx server block automatically.