tutorial

Monitoring Whoogle Search with Vigilmon: Web Availability, Search Endpoint, SSL Certificates & Instance Health

How to monitor your self-hosted Whoogle Search instance with Vigilmon — web availability checks, search endpoint correctness monitoring, SSL certificate alerts, and instance availability tracking so your private search proxy stays online.

Whoogle Search is the self-hosted Google search proxy that strips ads, tracking pixels, and JavaScript bloat from Google results — returning clean, relevant search output without sending your queries to Google directly. Once your team is routing searches through a private Whoogle instance, they depend on it being available every time someone needs to look something up. A downed Whoogle instance either means no search or falling back to tracked Google queries — the exact scenario your private instance was meant to prevent. Vigilmon monitors Whoogle's web interface, search endpoint responsiveness, and SSL certificate so your private search proxy stays up and reachable.

What You'll Build

  • An HTTP monitor for Whoogle web UI availability
  • A search endpoint monitor that verifies results are being returned correctly
  • Response time tracking for search latency
  • SSL certificate monitoring for your Whoogle domain

Prerequisites

  • A running Whoogle instance accessible via a domain (e.g., https://search.example.com)
  • HTTPS configured via reverse proxy
  • A free account at vigilmon.online

Step 1: Verify Whoogle Web UI Availability

Whoogle's root path serves the search input form. A healthy instance returns HTTP 200 with a minimal HTML page:

curl -I https://search.example.com
# Expected: HTTP/2 200

Whoogle is a Python Flask application. If the Flask process crashes, the WSGI server returns a 502 or the connection refuses entirely.

Step 2: Create a Vigilmon HTTP Monitor for Web Availability

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://search.example.com.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: search (present in the search form HTML).
  7. Label: Whoogle Web UI.
  8. Click Save.

This monitor catches:

  • Whoogle Flask process crashes or container exits
  • WSGI server (Gunicorn/uWSGI) failures
  • Reverse proxy configuration errors
  • Container OOM kills during memory-intensive sessions
  • Port binding failures after container restart

Step 3: Monitor the Search Endpoint for Correctness

A Whoogle instance can be running but broken — returning errors, blank results, or Google rate-limit responses — without the web UI monitor catching it. The search endpoint itself is the real functional test.

Whoogle proxies search queries through its /search path with a q parameter:

curl "https://search.example.com/search?q=test"
# Expected: HTTP 200 with HTML containing search results

A healthy response contains <div class="result" elements in the HTML. If Whoogle is being rate-limited by Google, the response may return 200 but with a CAPTCHA page rather than results.

  1. Add Monitor → HTTP.
  2. URL: https://search.example.com/search?q=test.
  3. Check interval: 5 minutes.
  4. Expected status: 200.
  5. Keyword: result.
  6. Label: Whoogle Search Endpoint.
  7. Click Save.

Why use a keyword check? Whoogle can return HTTP 200 with a Google CAPTCHA page or an error page when rate-limited or blocked. The keyword result verifies that the response contains actual search results, not a fallback error page. If you see frequent false alerts, try a more unique keyword from Whoogle's result HTML, such as the CSS class name used by your Whoogle version.

Rate limiting note: Whoogle rotates Google requests and supports custom Tor/SOCKS proxies to avoid rate limiting. If this monitor fires frequently, investigate whether your Whoogle instance is being rate-limited by Google rather than being down.

Step 4: Track Search Response Time

Whoogle must fetch results from Google and render them before responding. This makes it inherently slower than a local application — but if response times climb above 5–10 seconds, the search experience degrades to the point where users stop using the private instance.

  1. Open the Whoogle Search Endpoint monitor from Step 3.
  2. Navigate to Advanced → Response Time Threshold.
  3. Alert if response time exceeds: 8000 ms.
  4. Click Save.

Common causes of Whoogle response time increases:

  • Google rate limiting forcing retries or slower request routing
  • Network latency between your server and Google's endpoints
  • Tor/proxy routing latency if configured
  • Server CPU or memory pressure
  • Google changing its response format, causing Whoogle to spend more time parsing

Step 5: Monitor SSL Certificates

Whoogle is your privacy-first search interface — a browser warning about an invalid SSL certificate defeats its purpose by making users choose between accepting the risk and falling back to tracked Google search. SSL expiry on a Whoogle instance is particularly disruptive because users may not know to report it; they'll just stop using the private instance quietly.

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

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Web UI | Non-200 or keyword missing | Check Whoogle container; inspect Flask/Gunicorn logs | | Search Endpoint | Non-200 or result keyword missing | Check Google rate limiting; inspect Whoogle logs; verify proxy config | | Response Time | > 8 s | Investigate Google rate limiting; check network path to Google | | SSL Certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal |

Alert after: 2 consecutive failures for HTTP monitors. Whoogle occasionally has transient slowness due to Google-side variability — two consecutive failures confirm a real issue.

Monitoring Multiple Whoogle Instances

If you run multiple Whoogle instances (for redundancy, geographic distribution, or load balancing), add a monitor for each:

  1. Repeat Steps 2–5 for each instance URL.
  2. Group them under a Whoogle label prefix in Vigilmon for easy filtering.
  3. Consider different check intervals per region — a primary instance at 60 seconds, fallback instances at 5 minutes.

Running multiple instances protects against both application failures and Google rate limiting — if one instance gets rate-limited, traffic can shift to another.

Common Whoogle Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Flask process crash | Web UI monitor fires; 502 or connection refused | | Google rate limiting (CAPTCHA returned) | Search endpoint keyword check fails; web UI monitor stays green | | Tor/SOCKS proxy failure | Search endpoint returns errors; response time spikes | | Container OOM kill | Both monitors fire simultaneously | | SSL certificate expires | SSL monitor alerts at 30 days | | Google HTML structure change | Whoogle parser fails; search endpoint returns malformed results | | DNS misconfiguration | All monitors fire simultaneously | | Reverse proxy TLS termination fails | Web UI monitor fires with connection error |

Your team adopted Whoogle to search without being tracked — every hour your private instance is down is an hour of Google queries being attributed to your users. Vigilmon watches Whoogle's availability, search correctness, response time, and SSL certificate so you catch failures before your team quietly switches back to tracked search.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles