Monitoring Shlink with Vigilmon: REST API Alive Check, Web Dashboard Uptime, SSL Alerts & Health Endpoint

Shlink is a self-hosted URL shortener that gives you full control over your short links — from your own domain, without relying on Bit.ly or TinyURL. What makes Shlink downtime uniquely damaging is the cascading effect: every shortened URL your team has ever shared in emails, social media posts, printed materials, and QR codes stops working the moment Shlink goes offline. A single outage breaks links that may have been shared years ago to thousands of recipients. Vigilmon gives you external visibility into Shlink's REST API, web dashboard, and SSL certificate so your URL shortener is never silently returning 404s to everyone who clicks your links.

What You'll Build

• An HTTP monitor on Shlink's REST API endpoint (returning 401 = alive)
• An HTTP monitor for the web dashboard availability
• An SSL certificate monitor for your Shlink domain
• A TCP port check for your Shlink server
• An alerting setup tied to alert thresholds appropriate for a public-facing redirect service

Prerequisites

• A running Shlink instance with a public domain (e.g., https://s.example.com)
• HTTPS configured with a valid certificate
• Shlink's REST API enabled (the default)
• A free account at vigilmon.online

Step 1: Understand Shlink's Alive Signals

Shlink doesn't expose a dedicated /health endpoint in older versions, but the REST API itself is the liveness signal. Calling /rest/v3/short-urls without an API key returns HTTP 401 Unauthorized — which is exactly what you want. A 401 response means:

• The Shlink PHP process is running
• The routing layer is functioning
• The database connection is active (Shlink validates auth against DB)
• The web server (Apache, nginx, or Caddy) is passing requests through

curl -I https://s.example.com/rest/v3/short-urls

A healthy Shlink returns HTTP 401 with a JSON error body. This is your liveness check — no API key needed.

Step 2: Create a Vigilmon Monitor for the REST API

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://s.example.com/rest/v3/short-urls.
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 401.
6. Label: Shlink REST API.
7. Click Save.

Accepting a 401 as "healthy" is intentional — it means Shlink received the request, authenticated (or failed to authenticate), and responded normally. A 500, 502, or no response would indicate a real failure.

This monitor catches:

• PHP process crashes or OOM kills
• Database connectivity failures (Shlink can't validate the request)
• Web server misconfigurations after Shlink upgrades
• Container or VM restarts that left Shlink unavailable

Because every short URL redirect depends on Shlink being alive, a 60-second polling interval means you'll know within a minute when any of your shared links start returning errors.

Step 3: Monitor the Web Dashboard

Shlink ships with an optional web dashboard (or you may run shlink-web-client separately). This dashboard is what your team uses to manage URLs, view click statistics, and create new short links. Monitor it independently of the API:

1. Add Monitor → HTTP.
2. URL: https://s.example.com/ (or your dashboard URL if hosted separately).
3. Check interval: 5 minutes.
4. Expected status: 302 (Shlink root redirects to the dashboard path) or 200.
5. Label: Shlink Web Dashboard.
6. Click Save.

Note: Shlink's root path (/) typically returns a 302 redirect — this is expected and healthy behavior. Configure your monitor's expected status to match what your deployment returns. If Shlink is configured without the web client, the root path may return a 404 and you can skip this monitor.

This monitor catches reverse proxy failures and static asset serving problems that would prevent your team from managing short links in the browser, even when the API backend is running.

Step 4: Add a TCP Port Check

HTTP monitors catch application-level failures. A TCP monitor catches lower-level failures — a firewall rule change, a port that stopped listening, or a network partition — before they affect your monitors' ability to reach the HTTP endpoint:

1. Add Monitor → TCP Port.
2. Host: s.example.com.
3. Port: 443 (or 80 if you also run HTTP).
4. Check interval: 5 minutes.
5. Label: Shlink TCP 443.
6. Click Save.

A TCP check failure alongside an HTTP monitor failure confirms a network-layer problem rather than an application failure — useful for triaging whether to restart the app or check the firewall.

Step 5: Monitor SSL Certificates

Shlink's short links are often embedded in emails and printed materials where users can't easily see a browser certificate warning. If your SSL certificate expires:

• Every redirect through your short domain shows a "Your connection is not private" browser error
• Users will abandon the link rather than click through
• There's no way for users to distinguish "site is down" from "certificate expired"

1. Add Monitor → SSL Certificate.
2. Domain: s.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

If you use Let's Encrypt with auto-renewal (certbot, Caddy, or Traefik), a 30-day warning indicates the renewal automation has silently failed. Check your renewal cron job or reverse proxy logs before the deadline.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | REST API | Non-401 response | Check PHP-FPM/web server status; inspect Shlink logs | | Web Dashboard | Non-200/302 response | Check reverse proxy; verify static assets are served | | TCP Port | Connection refused | Check firewall rules; verify web server is listening | | SSL Certificate | < 30 days to expiry | Renew immediately; check auto-renewal automation |

Alert after: 2 failures for HTTP monitors (to avoid false positives from transient network issues). 1 failure for SSL certificate alerts.

Escalation: Configure a separate high-priority alert for SSL certificate expiry — an expired certificate breaks every link you've ever shared, not just the ones clicked in the next hour.

Common Shlink Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | PHP process crash | REST API returns 502/503; alert within 60 s | | Database connection failure | REST API returns 500 (DB auth fails); alert within 60 s | | Web server restart | TCP monitor fires first; HTTP monitors follow | | SSL certificate expires | SSL monitor alerts at 30-day threshold; browsers block links | | Container OOM kill | REST API unreachable; alert within 60 s | | Web dashboard assets missing | Dashboard monitor fires; API stays healthy | | Disk full (logs/SQLite) | Shlink may start failing writes; API may return 500 | | DNS misconfiguration | All HTTP and SSL monitors fire simultaneously | | Reverse proxy misconfiguration | HTTP monitors fire; TCP check stays green | | Shlink upgrade breaks routing | REST API returns unexpected status; alert immediately |

URL shortener downtime has a uniquely long tail: links you shared months ago keep getting clicked, and every one of those requests fails silently until you're alerted. Vigilmon watches Shlink's REST API, web dashboard, TCP port, and SSL certificate so you learn about failures within seconds — not when someone emails you a broken link.

Start monitoring Shlink in under 5 minutes — register free at vigilmon.online.