DEV Community: Serg Petrov

Docker Compose Is Documentation That Actually Runs

Serg Petrov — Wed, 28 Jan 2026 15:01:18 +0000

Two projects. Both have Dockerfiles. One takes me 20 minutes to figure out how to run. The other - 30 seconds.

The difference? The second one has a docker-compose.yml.

That file told me everything: what ports to expose, what services it depends on, what environment variables it needs, what volumes to mount. The Dockerfile only told me how to build.

Compose isn't just a convenience tool. It's executable documentation.

The "I'll Just Remember It" Trap

A year ago I was debugging a service that hadn't been touched in months. The Dockerfile was there. Clean, multi-stage, optimized. Professional.

No Compose file. Just a Dockerfile and a README that said "see Dockerfile."

How do I run it?

docker build -t myservice .
docker run myservice

Container crashes. Missing environment variables. Okay, which ones?

I open config/config.go. There's a struct with 15 fields loaded via envconfig. Three have defaults. The rest? Required, apparently. The README mentions DATABASE_URL and that's it - the rest are "obvious."

I check git history. Find a Slack message from six months ago:

"run it with -e DATABASE_URL=... -e REDIS_URL=... -e SECRET_KEY=... -v $(pwd)/config:/app/config -p 8080:8080 --network=backend"

This is not engineering. This is archeology.

Compose as the Single Source of Truth

Now compare:

services:
  myservice:
    build: .
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://db:5432/app
      - REDIS_URL=redis://redis:6379
      - SECRET_KEY=${SECRET_KEY}
    volumes:
      - ./config:/app/config
    depends_on:
      - db
      - redis

I open this file and I know everything:

What ports it exposes
What services it needs
What config it expects
What volumes it mounts

No Slack archeology. No guessing. The documentation is the code.

The "But I Only Have One Container" Argument

People say: "I don't need Compose, I only have one service."

I disagree. Here's why.

Reason 1: You'll forget.

docker run commands grow. First it's just -p 3000:3000. Then you add a volume. Then environment variables. Then a network. Six months later you have a 200-character command and zero memory of why each flag is there.

Reason 2: You'll hate yourself.

Coming back to a project after a few months:

docker run -d --name app -p 3000:3000 -v $(pwd):/app -v /app/node_modules -e NODE_ENV=development -e DATABASE_URL=postgres://... -e REDIS_URL=redis://... -e JWT_SECRET=... --network app-network app:dev

vs.

docker compose up

Reason 3: Compose files are diffable.

When someone changes the configuration, I see it in the PR. Clear diff. Clear history. With shell commands? Good luck tracking what changed.

The Things That Bit Me

depends_on Lies to You

I wrote this and expected it to work:

services:
  db:
    image: postgres:15

  app:
    build: .
    depends_on:
      - db

App crashed on startup. "Connection refused."

depends_on doesn't wait for the service to be ready. It waits for the container to start. Postgres takes a few seconds to initialize. My app tried to connect immediately. Boom.

The fix:

services:
  db:
    image: postgres:15
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 2s
      timeout: 5s
      retries: 10

  app:
    build: .
    depends_on:
      db:
        condition: service_healthy

Now Compose actually waits until Postgres responds to connections.

I've seen production deployments break because of this. People blame Docker. It's not Docker's fault - depends_on just doesn't do what you think it does. (docs)

Anonymous Volumes Are a Trap (docs)

This looks innocent:

volumes:
  - /app/node_modules

It creates an anonymous volume. Works great until you need to:

Find it (docker volume ls shows a random hash)
Back it up (which volume is which?)
Clean it up (orphaned volumes everywhere)

Named volumes:

volumes:
  - node_modules:/app/node_modules

volumes:
  node_modules:

Now it's called projectname_node_modules. Searchable. Deletable. Manageable.

The Override File Nobody Reads About

Compose automatically merges docker-compose.override.yml if it exists (docs). No flags needed. Same with .env - it loads automatically, no env_file directive required (docs).

I use this pattern:

docker-compose.yml - production-like defaults, committed:

services:
  app:
    image: myapp:1.2.3  # pin versions in prod, never use :latest
    environment:
      - NODE_ENV=production

docker-compose.override.yml - dev settings, also committed:

services:
  app:
    build: .
    volumes:
      - .:/app
    environment:
      - NODE_ENV=development

Run docker compose up - you get development mode.

Run docker compose -f docker-compose.yml up - you get production mode.

No separate "dev" and "prod" compose files. No confusion about which one to use.

The Pattern That Changed Everything

Profiles (docs). Added in Compose 1.28, still underused.

Before profiles, I had this mess:

docker-compose.yml
docker-compose.dev.yml
docker-compose.test.yml
docker-compose.monitoring.yml

With profiles:

services:
  app:
    build: .
    # Always runs

  db:
    image: postgres:15
    profiles: [dev]

  redis:
    image: redis:7
    profiles: [dev]

  prometheus:
    image: prom/prometheus
    profiles: [monitoring]

  grafana:
    image: grafana/grafana
    profiles: [monitoring]

  test-db:
    image: postgres:15
    profiles: [test]
    environment:
      - POSTGRES_DB=test

docker compose up                                    # just app
docker compose --profile dev up                      # app + db + redis
docker compose --profile monitoring up               # app + prometheus + grafana
docker compose --profile dev --profile monitoring up # combine profiles

One file. Clear intent. No YAML soup.

The Commands Nobody Told Me About

`docker compose up --wait` (docs)

Most people run docker compose up -d and then manually check if everything started. There's a better way:

docker compose up -d --wait

This returns control only when all services with healthchecks are healthy. Perfect for CI pipelines and scripts.

`docker compose config` (docs)

Your compose file uses variables and overrides. What's the actual final config?

docker compose config

Shows the fully resolved YAML after all interpolation and merging. Saved me hours of "why isn't this variable working" debugging.

`docker compose watch` (docs)

Volumes for hot reload are messy. They sync node_modules back and forth, cause permission issues, and slow things down.

Compose 2.22+ has a better way:

services:
  app:
    build: .
    develop:
      watch:
        - action: rebuild
          path: ./package.json
        - action: sync
          path: ./src
          target: /app/src

docker compose watch

File changes trigger rebuilds or syncs automatically. No bidirectional volume chaos.

Small Things That Matter

Environment variable defaults (docs)

services:
  app:
    ports:
      - "${PORT:-3000}:3000"
    environment:
      - LOG_LEVEL=${LOG_LEVEL:-info}

If the variable isn't set, use the default. No more "variable not found" crashes.

`init: true` (docs)

services:
  app:
    init: true

One line. Proper signal handling. No zombie processes. Your containers will actually stop when you ask them to.

tmpfs for test databases (docs)

services:
  test-db:
    image: postgres:15
    tmpfs: /var/lib/postgresql/data

Database runs entirely in memory. Tests run faster. Nothing persists between runs - which is exactly what you want for tests.

YAML anchors for DRY (docs)

x-logging: &default-logging
  logging:
    driver: json-file
    options:
      max-size: "10m"
      max-file: "3"

services:
  app:
    <<: *default-logging
    build: .

  worker:
    <<: *default-logging
    build: ./worker

Define once, reuse everywhere. The x- prefix marks it as an extension (docs) - Compose ignores it, but YAML anchors still work.

The Compose File as Contract

Here's how I think about it now.

A Dockerfile answers: "How do I build this?"

A docker-compose.yml answers: "How does this run in context?"

Context means:

What other services does it need?
What configuration does it expect?
What ports does it expose?
What data does it persist?

Without this context, a Dockerfile is just a build recipe. With Compose, it becomes a runnable system.

The best infrastructure is the one you don't have to explain. Write it down in a way that runs.

Why Most SSL Certificate Monitors Are Blind (And How to Fix It)

Serg Petrov — Thu, 22 Jan 2026 16:40:13 +0000

Google "golang check ssl certificate" and every example looks like this:

conn, _ := tls.Dial("tcp", "example.com:443",
    &tls.Config{InsecureSkipVerify: true})
cert := conn.ConnectionState().PeerCertificates[0]
fmt.Println(cert.NotAfter) // 2026-03-16

53 days left. Great. Ship it.

But your monitor just became blind to 3 out of 4 certificate problems.

The InsecureSkipVerify trap

InsecureSkipVerify: true skips all certificate validation - expiry, trust chain, hostname match. The connection is still encrypted, but Go won't check if the cert is actually valid.

Why do examples use it? Without it, Go refuses to connect if anything is wrong. You get an error instead of certificate details. For a quick script, that's inconvenient.

For monitoring, it's dangerous:

Problem	What users see	What your monitor shows
Self-signed cert	Browser warning	"53 days left"
Wrong domain	Browser warning	"53 days left"
Untrusted CA	Browser warning	"53 days left"
Expired cert	Browser warning	"Expired"

Three problems go undetected. Your monitor says everything is fine while users can't access your site.

The fix: two-step check

First, try a normal connection. If it succeeds, the certificate is valid. If it fails, make a second connection with InsecureSkipVerify to get the details anyway.

func checkCert(host string) CertStatus {
    status := CertStatus{Host: host}
    dialer := &net.Dialer{Timeout: 10 * time.Second}

    // Step 1: Try normal connection (validates certificate)
    conn, err := tls.DialWithDialer(dialer, "tcp", host+":443", nil)

    if err == nil {
        // Certificate is valid - get details
        cert := conn.ConnectionState().PeerCertificates[0]
        status.IsValid = true
        status.DaysLeft = int(time.Until(cert.NotAfter).Hours() / 24)
        conn.Close()
        return status
    }

    // Step 2: Validation failed - get details anyway
    status.ValidationError = err.Error()

    conn, err = tls.DialWithDialer(dialer, "tcp", host+":443",
        &tls.Config{InsecureSkipVerify: true})
    if err != nil {
        status.Error = err.Error()
        return status
    }
    defer conn.Close()

    cert := conn.ConnectionState().PeerCertificates[0]
    status.DaysLeft = int(time.Until(cert.NotAfter).Hours() / 24)
    return status
}

Now you see both: validity status AND expiry dates. A self-signed cert with 2 years left is still a problem your users will hit.

Complete monitor

package main

import (
    "crypto/tls"
    "fmt"
    "net"
    "time"
)

type CertStatus struct {
    Host            string
    ExpiresAt       time.Time
    DaysLeft        int
    Issuer          string
    IsValid         bool
    ValidationError string
    Error           string
}

func checkCert(host string) CertStatus {
    status := CertStatus{Host: host}
    dialer := &net.Dialer{Timeout: 10 * time.Second}

    // Step 1: Try normal connection (validates certificate)
    conn, err := tls.DialWithDialer(dialer, "tcp", host+":443", nil)

    if err == nil {
        cert := conn.ConnectionState().PeerCertificates[0]
        status.ExpiresAt = cert.NotAfter
        status.DaysLeft = int(time.Until(cert.NotAfter).Hours() / 24)
        status.Issuer = cert.Issuer.CommonName
        status.IsValid = true
        conn.Close()
        return status
    }

    // Step 2: Validation failed - get details anyway
    status.ValidationError = err.Error()

    conn, err = tls.DialWithDialer(dialer, "tcp", host+":443",
        &tls.Config{InsecureSkipVerify: true})

    if err != nil {
        status.Error = err.Error()
        return status
    }
    defer conn.Close()

    cert := conn.ConnectionState().PeerCertificates[0]
    status.ExpiresAt = cert.NotAfter
    status.DaysLeft = int(time.Until(cert.NotAfter).Hours() / 24)
    status.Issuer = cert.Issuer.CommonName

    return status
}

func main() {
    domains := []string{
        "github.com",
        "google.com",
        "expired.badssl.com",
        "self-signed.badssl.com",
        "wrong.host.badssl.com",
    }

    for _, domain := range domains {
        status := checkCert(domain)

        if status.Error != "" {
            fmt.Printf("ERR  %s: %s\n", domain, status.Error)
            continue
        }

        if !status.IsValid {
            fmt.Printf("FAIL %s: %s\n", domain, status.ValidationError)
            fmt.Printf("     expires: %s\n", status.ExpiresAt.Format("2006-01-02"))
            continue
        }

        switch {
        case status.DaysLeft < 7:
            fmt.Printf("CRIT %s: %d days left\n", domain, status.DaysLeft)
        case status.DaysLeft < 30:
            fmt.Printf("WARN %s: %d days left\n", domain, status.DaysLeft)
        default:
            fmt.Printf("OK   %s: %d days left\n", domain, status.DaysLeft)
        }
    }
}

Output:

OK   github.com: 73 days left
OK   google.com: 40 days left
FAIL expired.badssl.com: tls: failed to verify certificate: x509: certificate has expired or is not yet valid: "*.badssl.com" certificate is expired
     expires: 2015-04-12
FAIL self-signed.badssl.com: tls: failed to verify certificate: x509: certificate signed by unknown authority
     expires: 2028-01-20
FAIL wrong.host.badssl.com: tls: failed to verify certificate: x509: certificate is valid for *.badssl.com, badssl.com, not wrong.host.badssl.com
     expires: 2026-04-20

"But I have auto-renewal"

Let's Encrypt auto-renewal fails silently. DNS changed, server migrated, disk full, rate limits hit, nginx didn't reload after renewal. You won't know until users see browser warnings.

Always monitor even with auto-renewal.

Non-obvious gotchas

Wildcard doesn't cover what you think

*.example.com does NOT cover example.com (root) or api.staging.example.com (two levels deep). Monitor them separately.

Different certs behind load balancer

Three servers, each with its own certbot. One renewed, two didn't. 33% of users see errors. You can't reproduce it - you keep hitting the working server.

Monitor from multiple locations or run checks repeatedly.

This is how we monitor certificates at upsonar.io - but the code above works if you prefer to run your own.

How do you monitor your certificates?

Why .dev, .app, .page (and 40+ Other TLDs) Don't Respond to WHOIS

Serg Petrov — Tue, 06 Jan 2026 19:52:12 +0000

I was building upsonar.io - it monitors uptime, SSL certificates, and domain expiration. When I got to domain expiry alerts, I hit a wall.

Checked .com, .org, .net - worked fine. Then I tried google.dev.

Connection refused.

The Investigation

First thought: maybe Google blocks WHOIS queries for their domains? Let me check the WHOIS server for .dev:

$ whois -h whois.iana.org dev

Output (trimmed):

domain:       DEV
organisation: Charleston Road Registry Inc.
...
whois:

status:       ACTIVE
remarks:      Registration information: https://www.registry.google

See that empty whois: field? There's no WHOIS server for .dev at all.

Turns out, Google owns 40+ TLDs and none of them have a WHOIS server:

.app, .page, .new, .google, .youtube, .android, .chrome, .zip, .mov, .dad, .phd, .prof, .meme, .foo, .nexus, .rsvp, .fly, .ing, .boo, .channel...

You can check any TLD on IANA's root database - look for the "WHOIS Server" field.

This isn't a bug. It's by design.

Why No WHOIS?

Google launched these TLDs after 2012, when ICANN started pushing a new protocol called RDAP (Registration Data Access Protocol).

The main problem with WHOIS? No standard format. Every registrar returns different text, different field names, different date formats.

RDAP fixes this:

JSON responses - no more parsing random text formats, just json.Unmarshal
Standard field names - expiration date is always eventAction: "expiration", not "Expiry Date" vs "Registry Expiry Date" vs "paid-till"
RESTful API - just a GET request, works with any HTTP client

In January 2025, ICANN officially sunset WHOIS for gTLDs. RDAP is now the standard.

How to Check Domain Expiration with RDAP

If you want to monitor domain expiration or build a domain expiration lookup tool, RDAP is the way to go. Here's working Go code:

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "strings"
    "time"
)

func main() {
    domain := "google.dev"
    if len(os.Args) > 1 {
        domain = os.Args[1]
    }

    expiry, err := getExpiry(domain)
    if err != nil {
        fmt.Printf("Error: %v\n", err)
        return
    }

    days := int(time.Until(expiry).Hours() / 24)
    fmt.Printf("%s expires %s (%d days)\n", domain, expiry.Format("2006-01-02"), days)
}

func getExpiry(domain string) (time.Time, error) {
    tld := domain[strings.LastIndex(domain, ".")+1:]

    // RDAP endpoints (from IANA bootstrap file)
    endpoints := map[string]string{
        "com": "https://rdap.verisign.com/com/v1/domain/",
        "net": "https://rdap.verisign.com/net/v1/domain/",
        "org": "https://rdap.publicinterestregistry.org/rdap/domain/",
        "dev": "https://pubapi.registry.google/rdap/domain/",
        "app": "https://pubapi.registry.google/rdap/domain/",
        "io":  "https://rdap.nic.io/domain/",
    }

    endpoint, ok := endpoints[tld]
    if !ok {
        return time.Time{}, fmt.Errorf("unknown TLD: %s", tld)
    }

    resp, err := http.Get(endpoint + domain)
    if err != nil {
        return time.Time{}, err
    }
    defer resp.Body.Close()

    var data struct {
        Events []struct {
            Action string `json:"eventAction"`
            Date   string `json:"eventDate"`
        } `json:"events"`
    }

    json.NewDecoder(resp.Body).Decode(&data)

    for _, e := range data.Events {
        if e.Action == "expiration" {
            return time.Parse(time.RFC3339, e.Date)
        }
    }

    return time.Time{}, fmt.Errorf("no expiration date found")
}

Run it:

$ go run main.go google.dev
google.dev expires 2025-09-14 (252 days)

$ go run main.go github.com
github.com expires 2026-10-09 (642 days)

Clean JSON, standard fields, no parsing nightmares.

RDAP Coverage

All gTLDs (.com, .org, .dev, etc.) support RDAP. Most ccTLDs (.uk, .de, .ru, etc.) still rely on WHOIS, but coverage is growing every year.

The full list of RDAP endpoints is in IANA's bootstrap file - this is where you get the correct endpoint for any TLD.

Key Takeaways

New TLDs (especially Google's) have no WHOIS server - RDAP only
ICANN deprecated WHOIS in 2025 - RDAP is the future
RDAP returns JSON - no more parsing 50 different date formats

Don't want to deal with RDAP yourself? upsonar.io/docs/domain-expiry - monitors domain expiration and alerts before they expire. Free tier available.

This is part of the Building a Monitoring Tool in Go series. Follow for more.

What TLDs are you monitoring? Hit any weird edge cases?

How We Measure HTTP Timing: DNS, TCP, TLS, TTFB Breakdown

Serg Petrov — Thu, 01 Jan 2026 16:55:54 +0000

When you check a website's response time, "847ms" doesn't tell you much. Is it slow DNS? Network latency? The server itself? You need a breakdown.

At upsonar.io we show exactly where the time goes. Here's how we do it with Go's net/http/httptrace package.

The problem

start := time.Now()
resp, _ := http.Get("https://example.com")
fmt.Println(time.Since(start)) // 847ms

847ms. But why? Could be anything.

The solution

httptrace hooks into every phase of an HTTP request. You attach callbacks, and they fire as each phase completes:

trace := &httptrace.ClientTrace{
    DNSStart: func(_ httptrace.DNSStartInfo) {
        dnsStart = time.Now()
    },
    DNSDone: func(_ httptrace.DNSDoneInfo) {
        fmt.Printf("DNS: %v\n", time.Since(dnsStart))
    },
    // same pattern for TCP, TLS, etc.
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

What each metric means

DNS Lookup - resolving domain to IP. Slow (100ms+) means DNS server issues or cold cache.

TCP Connect - the three-way handshake. Mostly about physical distance to the server.

TLS Handshake - negotiating encryption. Usually 50-150ms. Over 300ms means something's off - slow server or problematic certificate chain.

TTFB - time to first byte. Includes DNS + TCP + TLS + server processing. This is the standard metric for measuring response speed.

Transfer - downloading the response body.

Working example

package main

import (
    "crypto/tls"
    "fmt"
    "io"
    "net/http"
    "net/http/httptrace"
    "os"
    "time"
)

func main() {
    url := "https://httpbin.org/delay/2"
    if len(os.Args) > 1 {
        url = os.Args[1]
    }

    var dnsStart, tcpStart, tlsStart time.Time
    totalStart := time.Now()

    trace := &httptrace.ClientTrace{
        DNSStart:          func(_ httptrace.DNSStartInfo) { dnsStart = time.Now() },
        DNSDone:           func(_ httptrace.DNSDoneInfo) { fmt.Printf("DNS:  %v\n", time.Since(dnsStart)) },
        ConnectStart:      func(_, _ string) { tcpStart = time.Now() },
        ConnectDone:       func(_, _ string, _ error) { fmt.Printf("TCP:  %v\n", time.Since(tcpStart)) },
        TLSHandshakeStart: func() { tlsStart = time.Now() },
        TLSHandshakeDone:  func(_ tls.ConnectionState, _ error) { fmt.Printf("TLS:  %v\n", time.Since(tlsStart)) },
        GotFirstResponseByte: func() { fmt.Printf("TTFB: %v\n", time.Since(totalStart)) },
    }

    req, _ := http.NewRequest("GET", url, nil)
    req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

    client := &http.Client{Transport: &http.Transport{DisableKeepAlives: true}}
    resp, err := client.Do(req)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    defer resp.Body.Close()

    transferStart := time.Now()
    io.ReadAll(resp.Body)
    fmt.Printf("Transfer: %v\n", time.Since(transferStart))
    fmt.Printf("Total: %v\n", time.Since(totalStart))
}

go run main.go https://httpbin.org/delay/2

Output:

DNS:  148.00525ms
TCP:  142.56925ms
TLS:  289.685ms
TTFB: 2.956339583s
Transfer: 72.208µs
Total: 2.95670575s

TTFB is everything until the first byte arrives. Transfer is downloading the body - here it's tiny. Total = TTFB + Transfer.

With a larger response, Transfer becomes significant:

go run main.go https://proof.ovh.net/files/10Mb.dat

DNS:  3.621333ms
TCP:  54.364208ms
TLS:  116.879041ms
TTFB: 286.073291ms
Transfer: 14.221007833s
Total: 14.507351083s

Same TTFB formula, but now Transfer dominates - 14 seconds to download 10MB.

Watch out for connection reuse

Go's http.Client reuses connections by default. Second request to the same host - DNS, TCP, TLS all show 0ms.

For accurate measurements, disable keep-alives:

client := &http.Client{
    Transport: &http.Transport{
        DisableKeepAlives: true,
    },
}

What slow numbers tell you

DNS > 100ms → Try a faster DNS provider (Cloudflare, Google)
TCP > 100ms → Server is far from users, consider a CDN
TLS > 200ms → Check certificate chain, enable session resumption
TTFB > 500ms → Backend problem: slow database, cold starts, heavy processing
Transfer high → Large response, enable gzip/brotli compression

The 200ms rule

Users notice delays over 200ms. If your TTFB alone exceeds that, the page will feel slow - no matter how optimized your frontend is.

Try it on your site: upsonar.io/tools/diagnose - free, no signup.

What tools do you use for debugging slow requests?

When 200 OK Doesn't Mean Everything Is OK

Serg Petrov — Sat, 27 Dec 2025 13:12:54 +0000

Why Your Uptime Monitor Lies to You (And What I Built Instead)

Last year my site went down. Well, not really "down" — the server was fine. But users saw a broken page because Cloudflare had issues and my CSS wasn't loading.

My uptime monitor? Green checkmarks everywhere. 100% uptime. Great job.

That's when I realized: traditional monitoring is broken.

The lie of "200 OK"

Every uptime tool does the same thing:

GET https://your-site.com → 200 OK → "All good!"

But your site isn't just your server. It's:

Fonts from Google
JS bundles from your CDN
Payment forms from Stripe
Images from S3
Chat widgets, analytics, whatever else

If any of these break, users see a broken page. Your server is fine. Your monitoring is green. Your users are angry.

Remember when AWS S3 went down and half the internet broke? Or those Cloudflare incidents that took out millions of sites? Your server was probably fine during all of that. Your uptime monitor probably said everything was OK.

So I built something different

I made upsonar.io. It checks your site like a real browser would:

Load the page
Find all external resources (scripts, styles, images, fonts)
Check each one
Tell you what's actually broken

Here's what a real check looks like:

example.com: 200 OK ✓
├── fonts.googleapis.com → 200 ✓
├── cdn.example.com/app.js → 200 ✓
├── js.stripe.com/v3 → 200 ✓
├── s3.amazonaws.com/images/hero.webp → 503 ✗
└── widget.intercom.io → timeout ✗

Result: 3/5 dependencies working

Now you know the real picture.

How it works

┌──────────────┐      ┌──────────────┐      ┌─────────────┐
│   Frontend   │ ───▶ │   Go API     │ ───▶ │    Redis    │
│  React/Vite  │      │    Echo      │      │    Cache    │
└──────────────┘      └──────┬───────┘      └─────────────┘
                             │
           ┌─────────────────┼─────────────────┐
           ▼                 ▼                 ▼
    ┌────────────┐    ┌────────────┐    ┌────────────┐
    │  Sydney    │    │ Amsterdam  │    │  New York  │
    │ (DO Func)  │    │ (DO Func)  │    │ (DO Func)  │
    └─────┬──────┘    └─────┬──────┘    └─────┬──────┘
          │                 │                 │
          └─────────────────┼─────────────────┘
                            ▼
                    ┌──────────────┐
                    │ Your Website │
                    └──────────────┘

The idea: checks run from where your users actually are. Not from one datacenter.

9 regions right now: Sydney, Singapore, Amsterdam, Frankfurt, London, New York, San Francisco, Toronto, Bangalore. Each one is a serverless function on DigitalOcean — no servers to manage, scales automatically.

What happens on each check:

Scheduler triggers (every 1-5 minutes depending on your plan)
API fans out requests to all selected regions in parallel
Each function does its thing:
- HTTP request with detailed timing
- Parse HTML, find all external resources
- Check each resource (limited concurrency so we don't hammer the target)
Results come back, get cached in Redis
If status changed from last check → notification goes out

The serverless part is nice. Cold starts add maybe 200-300ms, but for monitoring that's fine. And I don't have to babysit servers in 9 datacenters.

Tech stuff (for the curious)

Backend is Go with Echo. Why Go? The net/http/httptrace package is amazing for measuring exactly where time goes in a request. Plus goroutines make it easy to check 50 resources in parallel without the code turning into callback soup.

Frontend is React + Vite. Database is just SQLite — simple, no separate service to manage, works fine for this scale.

The interesting bits:

HTML parsing to extract resources (handling srcset, lazy loading, relative URLs)
Semaphore pattern for concurrent resource checks (don't want to DDoS the target)
TLS probing to check which protocols and ciphers a server supports

I'll write about each of these separately.

Try it

Free tools, no signup:

Check availability from 9 regions
Check SSL certificate — expiry, chain, TLS config
Check domain expiry — WHOIS lookup
Full health check — timing breakdown, security headers, dependencies

For continuous monitoring there's a free tier — 3 sites, checks every 5 minutes.

What's next

Planning to write about:

Measuring HTTP phases with Go's httptrace
Parsing HTML for resource URLs (it's trickier than you'd think)
Testing TLS versions programmatically
Concurrent HTTP requests without killing the target

Follow if you're interested.

What do you use for monitoring? Curious if others have hit similar issues with "false positives" from traditional uptime tools.