Monitoring Chhoto URL Shortener with Vigilmon

Chhoto is a lightweight, self-hosted URL shortener written in Rust with a minimal web UI and REST API. It's designed for simplicity: a tiny binary, a single SQLite file, and near-zero memory usage. Teams use it for internal link management, marketing campaign tracking, and sharing long URLs through memorable short codes. But simple doesn't mean zero-maintenance — when Chhoto goes down, every short link in your organization stops redirecting. A broken URL in a marketing email, a slide deck, or a customer-facing document becomes a dead end that's hard to trace back to a server issue. Vigilmon monitors Chhoto's web server, redirect path, and API endpoints so you know the moment short links stop working.

What You'll Set Up

• Web server process availability monitor (port 4567)
• Shortlink redirect health check (core redirect path)
• Shortlink creation API endpoint check (POST /api/new)
• SQLite database accessibility via cron heartbeat
• Statistics endpoint health check (if enabled)
• TLS certificate expiry alerts

Prerequisites

• Chhoto running and accessible (default port: 4567)
• A test short code pre-created for monitoring (e.g., healthcheck → your server's own URL)
• A free Vigilmon account

Step 1: Monitor Web Server Availability

The first and most fundamental check: is the Chhoto process running and accepting connections?

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. URL: https://go.yourdomain.com (or http://localhost:4567 for a local install).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

Chhoto's root path (/) serves the web UI for creating and listing short links. A 200 here confirms the Actix-web server process is running and handling requests. If Chhoto crashes — OOM kill, segfault, systemd restart — this monitor fires immediately.

Step 2: Monitor the Core Redirect Path

The entire value of a URL shortener is its redirect functionality: GET /:shortcode looks up the target URL in SQLite and returns a 301/302 redirect. This is the path that matters to your users — and it's what breaks if Chhoto is down or if SQLite is corrupted.

Before you can monitor this, create a dedicated health-check short code:

# Create a health-check shortcode pointing to your Chhoto instance itself
curl -X POST https://go.yourdomain.com/api/new \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{"shortcode": "healthcheck", "url": "https://go.yourdomain.com"}'

Now set up the Vigilmon monitor for the redirect:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://go.yourdomain.com/healthcheck
3. Set Expected HTTP status to 301 or 302 (Chhoto returns a redirect, not a 200).
4. Enable Follow redirects: disabled (you want to check the redirect response itself, not the final destination).
5. Interval: 1 minute.
6. Save.

This monitor validates the full shortlink path: HTTP request → Actix-web route handler → SQLite lookup → redirect response. A 404 means the shortcode was deleted or the database is missing it. A 500 or timeout means the database query is failing.

Step 3: Monitor the Shortlink Creation API

The create endpoint — POST /api/new — is the write path for Chhoto. If this endpoint is broken, users can't create new short links (though existing links continue redirecting if the read path is healthy).

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://go.yourdomain.com/api/new
3. Method: GET
4. Expected status: 405 (Method Not Allowed — a GET to a POST-only endpoint confirms the route is registered and the handler is running).
5. Interval: 2 minutes.
6. Save.

A 405 response is a healthy signal from the create API — it means the Actix-web route for POST /api/new is registered. If the route returns 404, Chhoto's routing is broken. If it times out, the process may be hung.

If you want to verify the full write path including database writes, use a cron heartbeat approach instead. See Step 5 for an end-to-end write health check using a script.

Step 4: Monitor SQLite Database Accessibility

Chhoto stores all shortcode-to-URL mappings in a single SQLite file. SQLite is reliable, but problems can occur: the file can be deleted by mistake, the filesystem can fill up preventing writes, or file permissions can change after a server migration.

SQLite is local to the Chhoto process — there's no TCP port to probe from Vigilmon. Use a cron heartbeat that validates both read and write access:

#!/bin/bash
# Test SQLite read and write via the Chhoto API
# Read: verify the healthcheck shortcode still resolves
READ_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  --max-redirs 0 \
  https://go.yourdomain.com/healthcheck)

# Write: create/update a shortcode to verify write access
WRITE_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  -X POST https://go.yourdomain.com/api/new \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{"shortcode": "db-write-test", "url": "https://go.yourdomain.com"}')

# Ping heartbeat only if both checks passed
if [[ "$READ_STATUS" =~ ^30[12]$ ]] && [[ "$WRITE_STATUS" =~ ^20[01]$ ]]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_TOKEN
fi

Set this up in Vigilmon:

1. Click Add Monitor → Cron Heartbeat.
2. Set expected ping interval: 5 minutes.
3. Copy the heartbeat URL and paste it into your script.
4. Schedule the script on your server: */5 * * * * /opt/scripts/chhoto-health.sh

If the SQLite file is missing, permissions are broken, or the database is corrupted, the API calls return errors and the heartbeat stops pinging — Vigilmon alerts after the interval passes.

Step 5: Monitor API Authentication Health

If Chhoto is configured with an API key (the PASSWORD environment variable), write operations require an x-api-key header. An authentication misconfiguration after a config change or container rebuild causes all write operations to fail with 401.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://go.yourdomain.com/api/new
3. Method: POST
4. Body: {"shortcode": "auth-test", "url": "https://example.com"}
5. Headers: Content-Type: application/json, x-api-key: YOUR_API_KEY
6. Expected status: 200 or 201.
7. Interval: 5 minutes.
8. Save.

Note: Store the API key in Vigilmon's monitor configuration, not in a shared document. Rotate the key in both Chhoto's environment and Vigilmon's monitor config when it changes. A 401 response here indicates either the key was changed and not updated in the monitor, or Chhoto was restarted with an incorrect config.

Step 6: Monitor Shortcode Lookup Performance

Chhoto is written in Rust for a reason — redirects should be sub-millisecond. If redirect latency climbs (SQLite lock contention, disk I/O pressure, high concurrent load), your short links still work but feel sluggish.

Vigilmon tracks response times on HTTP monitors automatically. To make latency visible:

1. Open the redirect monitor from Step 2 (/healthcheck).
2. In the monitor settings, set a Response time alert threshold (if available in your Vigilmon plan) to alert when redirect latency exceeds 200ms.
3. Save.

For a Rust/Actix app on reasonable hardware, redirect latency above 100ms indicates a system-level problem (disk pressure, CPU saturation) rather than an application issue. The threshold gives you an early warning before users notice sluggish redirects.

Step 7: Monitor the Statistics Endpoint

If Chhoto's click counting is enabled, the statistics endpoint — GET /api/stats/:shortcode — shows how many times a short link has been followed. This endpoint reads from SQLite like the redirect handler, so a failure here is often a leading indicator of redirect failures.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://go.yourdomain.com/api/stats/healthcheck
3. Method: GET
4. Add x-api-key header if the stats endpoint requires authentication.
5. Expected status: 200.
6. Interval: 5 minutes.
7. Save.

A 200 here with a JSON body containing click counts confirms the SQLite read path is healthy. If statistics are disabled in your Chhoto config, skip this step.

Step 8: TLS Certificate Expiry Monitoring

Enable SSL certificate monitoring on your main web server monitor:

1. Open the HTTP monitor for https://go.yourdomain.com.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Save.

Expired TLS certificates on URL shorteners are particularly damaging. Short links are often embedded in places where users can't see a detailed error message — a marketing email, a printed QR code, a slide deck. When the certificate expires, the link stops working silently from the user's perspective. A 21-day alert gives you time to renew before any embedded links are affected.

Step 9: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add your preferred notification target: Slack, email, or a webhook.
2. For the web server monitor and the redirect monitor, set Consecutive failures before alert to 2 — Chhoto restarts fast (Rust binary, no JVM warmup) but a single probe during restart would be a false positive.
3. For the SQLite cron heartbeat, set the alert threshold to 1 missed ping — a missed heartbeat means both read and write checks failed, which is an immediate outage.
4. For the TLS certificate monitor, set Consecutive failures before alert to 1.

If your short links are customer-facing (marketing campaigns, support documentation), route the redirect monitor to an on-call channel. Route the API creation and statistics monitors to a lower-urgency channel — they don't affect existing links.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP uptime | https://go.yourdomain.com | Chhoto process down | | Redirect check | GET /healthcheck (301/302) | Core redirect broken, SQLite read failure | | Create API | GET /api/new (405) | Route handler down | | SQLite cron heartbeat | Heartbeat URL | Database read/write failure | | Auth health | POST /api/new with API key | Authentication misconfiguration | | Stats endpoint | GET /api/stats/healthcheck | Stats read path broken | | SSL certificate | HTTPS endpoint | TLS expiry |

Chhoto's appeal is its simplicity — a Rust binary, a SQLite file, and a port. But that simplicity means there's no built-in health dashboard, no database connection pool metrics, and no built-in alerting when the process crashes. With Vigilmon watching the redirect path, the write API, and the TLS certificate, you'll know the moment a short link stops working — before it surfaces as a broken link in a customer-facing email or a dead QR code on a printed flyer.