Monitoring Typesense with Vigilmon: Health Endpoint, Collections API, TCP Port 8108 & SSL Alerts

Typesense is the fast, open-source search engine built as a self-hostable alternative to Algolia — delivering typo-tolerant, faceted search results in milliseconds with a simple REST API. Development teams embed Typesense into e-commerce storefronts, SaaS applications, and internal tools to power instant search bars, autocomplete, and filtered result sets. Typesense sits in the hot path of user-facing search — if the engine goes down, your search bar returns errors, filtered product listings break, and autocomplete stops working across every page that depends on it. Vigilmon gives you external visibility into Typesense's health endpoint, collections API, TCP port, and SSL certificate so you're alerted before search failures reach your users.

What You'll Build

• A monitor on Typesense's /health endpoint
• A liveness check on the Collections API (401 = alive)
• A TCP monitor for port 8108 availability
• SSL certificate monitoring for your Typesense domain

Prerequisites

• A running Typesense instance with a public or network-reachable domain
• HTTPS configured via a reverse proxy (e.g., https://search.example.com) or Typesense's built-in TLS
• Port 8108 accessible from Vigilmon's monitoring infrastructure (or 443 if behind a reverse proxy)
• A free account at vigilmon.online

Step 1: Verify Typesense's Health Endpoint

Typesense exposes a dedicated health check at /health that requires no authentication and is specifically designed for uptime monitoring:

curl https://search.example.com/health

A healthy Typesense instance returns HTTP 200 with:

{"ok":true}

This endpoint confirms the Typesense server process is running, the data directory is accessible, and the engine is ready to serve search requests. The ok: true field is Typesense's own readiness signal.

Step 2: Create a Vigilmon HTTP Monitor for the Health Endpoint

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://search.example.com/health.
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: true.
7. Label: Typesense Health.
8. Click Save.

This monitor catches:

• Typesense process crashes or container restarts
• Data directory corruption that prevents the engine from initializing
• Out-of-memory conditions (Typesense holds its indexes in memory for fast lookups)
• Configuration errors after upgrades that prevent the engine from starting

The keyword true is Typesense's own readiness signal — it's the most direct indicator that the search engine is operational and serving requests.

Step 3: Monitor the Collections API for Liveness

Typesense's collections API at /collections lists all search indexes (collections) and requires authentication via the X-TYPESENSE-API-KEY header. Without credentials, it returns HTTP 401 Unauthorized — which confirms the API layer is alive and routing requests correctly:

curl -I https://search.example.com/collections
# Expected: HTTP/1.1 401 Unauthorized

1. Add Monitor → HTTP.
2. URL: https://search.example.com/collections.
3. Check interval: 5 minutes.
4. Expected status: 401.
5. Label: Typesense Collections API.
6. Click Save.

Why monitor a 401? An HTTP 401 from /collections means Typesense received the request, processed it through its authentication middleware, and correctly rejected it because no API key was provided. This is distinct from a 502 Bad Gateway (reverse proxy can't reach Typesense) or a connection timeout (process not running). The 401 proves the complete request path — network, reverse proxy, and Typesense application — is functioning.

If you want to verify that your search indexes are actually populated, create a second monitor using a read-only API key and checking for the name field in the collections JSON response — an empty collections array with a running Typesense server indicates a failed data ingestion pipeline.

Step 4: Create a TCP Monitor for Port 8108

Typesense listens on port 8108 by default. A TCP check at this port confirms the Typesense process is running and bound to the network interface, independently of the application-level health response:

1. Add Monitor → TCP.
2. Host: search.example.com.
3. Port: 8108.
4. Check interval: 60 seconds.
5. Response timeout: 10 seconds.
6. Label: Typesense TCP 8108.
7. Click Save.

Reverse proxy setup: If Typesense is behind nginx, Caddy, or another reverse proxy and port 8108 is not publicly exposed, target the host's internal address where port 8108 is reachable. If the port is not accessible externally, rely on the /health endpoint as your primary health signal.

When the TCP monitor fires but the health endpoint monitor is also failing, the Typesense process has stopped or its port is blocked. When the TCP monitor fires but the HTTP health monitor is still green, a firewall or routing change has blocked port 8108 specifically — a network-level issue rather than an application failure.

Step 5: Monitor SSL Certificates

Typesense handles search traffic from browsers, mobile applications, and backend services. An expired SSL certificate:

• Breaks search bars and autocomplete across every page that calls the Typesense API
• Prevents mobile applications from making search API calls
• Causes browser-side Typesense clients to throw certificate errors for end users
• Blocks backend indexing pipelines that push documents into Typesense over HTTPS

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 | |---|---|---| | /health | Non-200 or true missing | Check Typesense process; inspect data directory; review memory usage | | Collections API | Non-401 response | If 502, reverse proxy can't reach Typesense; check container status | | TCP Port 8108 | Connection refused or timeout | Check Typesense process; verify port binding; inspect firewall rules | | 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. 1 failure for the TCP monitor — a process that stops binding to its port won't recover without intervention.

Common Typesense Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Typesense process crash | Health endpoint unreachable; alert within 60 s | | Out-of-memory kill (large indexes in RAM) | Process OOM-killed; health endpoint and TCP monitor fire | | Port 8108 blocked by firewall | TCP monitor fires; HTTP monitors via reverse proxy may stay green | | Data directory corruption | Typesense fails to start; health endpoint unreachable | | Empty collections after indexing failure | Collections API returns empty array; search returns no results silently | | Typesense upgrade breaks API schema | Health returns 200 but collections API response changes | | SSL certificate expires | SSL monitor alerts at 30 days; all HTTPS search calls fail in browser | | Disk full → can't persist new documents | Health may stay green but document writes fail silently | | DNS misconfiguration | All monitors fire simultaneously |

Search is often the feature users interact with most — and the one they notice immediately when it breaks. Typesense's speed makes it an excellent choice for real-time search, but external monitoring is what keeps it reliable. Vigilmon watches the health endpoint, collections API, TCP port, and SSL certificate so you're alerted the moment Typesense stops serving search requests, before your users notice the search bar is returning nothing.

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