Miniflux is the minimalist, self-hosted RSS reader that developers, researchers, and information professionals run on their own servers to follow hundreds of feeds without depending on a third-party service. Unlike a hosted RSS reader, Miniflux is a live Go application backed by a PostgreSQL database that handles feed polling, article storage, read/unread state, and API access for integrations with tools like Reeder, NetNewsWire, and custom automation pipelines. RSS readers are low-profile infrastructure — teams don't think about them until they go down — but they're often central to how engineers track security advisories, monitor competitor releases, follow upstream project changelogs, and stay informed on the technology landscape. When Miniflux goes down, articles stop updating, integrations break, and the information gap compounds quietly over hours or days. Vigilmon gives you external visibility into Miniflux's root path redirect, healthcheck endpoint, API liveness, and SSL certificate so you're notified the moment your feed reader becomes unreachable.
What You'll Build
- An HTTP monitor for the Miniflux root path redirect
- A liveness check on the
/healthcheckendpoint - A liveness check on the API endpoint (
/v1/mereturning 401 = service alive) - SSL certificate monitoring for your Miniflux domain
Prerequisites
- A running Miniflux instance with a public or network-reachable domain
- HTTPS configured via a reverse proxy (e.g.,
https://rss.example.com) - A free account at vigilmon.online
Step 1: Understand the Miniflux Root Path
Miniflux redirects unauthenticated root path requests to the login page. This makes the redirect itself a useful health signal:
curl -I https://rss.example.com
# Expected: HTTP 302 redirect to /login
A 302 response confirms the Go application is running and handling requests. If Miniflux is down, you'll get a 502 Bad Gateway from the reverse proxy, a connection timeout, or a 503 Service Unavailable — not a redirect.
Step 2: Create a Vigilmon HTTP Monitor for the Root Path
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://rss.example.com. - Check interval: 60 seconds.
- Response timeout: 10 seconds.
- Expected status:
302. - Label:
Miniflux Root Redirect. - Click Save.
Note on status codes: Miniflux returns
302(temporary redirect) to/loginfor unauthenticated root path requests. If your Vigilmon monitor follows redirects by default, set the expected status to200and addMinifluxas the keyword instead, so the monitor checks the final destination of the redirect.
This monitor catches:
- Miniflux Go process crashes or container restarts
- PostgreSQL database connection failures that prevent the application from starting
- Reverse proxy misconfigurations that return 502 instead of routing to Miniflux
- Out-of-memory kills that terminate the process
Step 3: Monitor the /healthcheck Endpoint
Miniflux exposes a /healthcheck endpoint designed specifically for health probes. It returns a simple response confirming the application is alive:
curl https://rss.example.com/healthcheck
# Expected: HTTP 200
A healthy response:
OK
- Add Monitor → HTTP.
- URL:
https://rss.example.com/healthcheck. - Check interval: 60 seconds.
- Expected status:
200. - Keyword:
OK. - Label:
Miniflux Healthcheck. - Click Save.
The /healthcheck endpoint is the most direct liveness signal Miniflux provides — it's served by the application itself and does not go through authentication middleware. Monitoring it separately from the root path gives you a clean, unambiguous signal that the Miniflux process is alive and responsive.
Step 4: Monitor the API Endpoint for Service Liveness
Miniflux provides a REST API at /v1. The /v1/me endpoint returns user information for authenticated requests. Without authentication, it returns HTTP 401 Unauthorized — but that 401 response is itself the proof that the application is alive, the API router is functional, and the request path is working end-to-end:
curl https://rss.example.com/v1/me
# Expected: HTTP 401 Unauthorized
A typical response:
{"error_message":"Access Unauthorized"}
- Add Monitor → HTTP.
- URL:
https://rss.example.com/v1/me. - Check interval: 2 minutes.
- Expected status:
401. - Keyword:
error_message. - Label:
Miniflux API Liveness. - Click Save.
Why monitor a 401? An
HTTP 401from/v1/memeans the Go application received the request, routed it through the API middleware, checked authentication, and responded with a structured error. A502 Bad Gatewaymeans the reverse proxy couldn't reach the application at all. The 401 is the liveness signal — it proves the entire request chain from the external network through the reverse proxy to the Go application is functional. Your RSS integrations (Reeder, NetNewsWire, fever-compatible clients) depend on this API path to sync read state and fetch new articles.
Step 5: Monitor SSL Certificates
Miniflux's API is consumed by RSS client apps on every device your team uses. An expired SSL certificate:
- Causes all Fever-compatible and Miniflux-API RSS clients to stop syncing
- Breaks any automation scripts or webhooks that post to the Miniflux API
- Prevents web browser access to the reading interface
- Triggers TLS certificate errors in mobile apps (iOS Reeder, Unread, Lire, etc.)
- Add Monitor → SSL Certificate.
- Domain:
rss.example.com. - Alert when expiry is within: 30 days.
- Alert again: 14 days, 7 days, 3 days, 1 day.
- Click Save.
RSS client apps typically show generic "connection failed" errors rather than explicit certificate warnings — users may spend time troubleshooting their app configuration rather than checking the server certificate. Catching certificate expiry 30 days early eliminates this class of confusion entirely.
Step 6: Configure Alerting
In Vigilmon under Settings → Notifications, configure your alert channels:
| Monitor | Trigger | Action | |---|---|---| | Root Redirect | Non-302 response | Check Miniflux container; inspect PostgreSQL connectivity; check reverse proxy | | Healthcheck | Non-200 or keyword missing | Miniflux process is down or degraded; restart container; check system resources | | API Liveness | Non-401 response | API layer failure; check application logs; inspect database query performance | | SSL certificate | < 30 days to expiry | Renew certificate; verify ACME/Let's Encrypt auto-renewal is running |
Alert after: 2 consecutive failures for HTTP monitors. Miniflux is a stable Go application with low resource requirements — a second failure reliably indicates a real outage.
Common Miniflux Failure Modes and What Vigilmon Catches
| Scenario | Vigilmon monitor | |---|---| | Miniflux process crash | Root redirect and healthcheck monitors fire; alert within 60 s | | PostgreSQL database unavailable | Application fails to start; all HTTP monitors fire | | PostgreSQL connection pool exhausted | Application slows; API requests time out; monitors fire | | Database migration failure after upgrade | Miniflux exits during startup; all monitors fire | | Reverse proxy misconfiguration | Root redirect fires (502 instead of 302); application may be healthy | | Feed polling loop crash | Application may still serve requests; articles stop updating silently | | Out-of-memory kill | Go process terminated; all monitors fire simultaneously | | SSL certificate expires | SSL monitor alerts at 30 days; all RSS client apps disconnect | | Port conflict after server restart | Miniflux fails to bind; all monitors fire | | DNS misconfiguration | All monitors fire simultaneously | | Disk full (PostgreSQL data directory) | Database write errors; feed updates fail; application may crash |
RSS readers are quiet infrastructure — they run unattended, do their job reliably, and attract attention only when they stop working. But for engineers tracking security CVEs, upstream changelogs, and technology news, Miniflux is the morning briefing they depend on. Vigilmon watches Miniflux's root path redirect, healthcheck endpoint, API liveness, and SSL certificate so you're alerted within 60 seconds of any failure — before the information gap grows from minutes into hours.
Start monitoring Miniflux in under 5 minutes — register free at vigilmon.online.