Your product analytics were down for six hours last Tuesday. Events from your mobile app stopped ingesting at 3 AM. No errors in the UI, no alerts from your team — just six hours of product data that vanished. You found the gap in your funnel charts the next morning.
PostHog is an open-source product analytics platform — a self-hosted alternative to Mixpanel and Amplitude — built on Django, Celery workers, ClickHouse for analytics storage, and Kafka for event ingestion. If any of those layers fails, events are silently dropped. Vigilmon gives you the external monitoring layer that catches ingestion failures, API downtime, and silent worker deaths before you lose irreplaceable data.
This tutorial covers monitoring a self-hosted PostHog instance end-to-end.
What You'll Build
- An HTTP monitor on PostHog's
/_health/endpoint - An ingestion API availability monitor
- A web UI monitor
- SSL certificate expiry alerts
Prerequisites
- A self-hosted PostHog instance (PostHog 1.43+ or PostHog Cloud self-hosted)
- A free account at vigilmon.online
Step 1: Monitor PostHog's Health Endpoint
PostHog exposes a dedicated health check at /_health/. This endpoint checks that Django is running and that connected services (PostgreSQL, Redis) are reachable. It's designed for load balancers and external monitors.
Test it:
curl -s https://posthog.yourdomain.com/_health/
Expected response:
{"status": "ok"}
A non-200 response means the Django backend is down, a dependent service is unreachable, or PostHog is in a degraded state.
Set up the Vigilmon monitor:
- Log in to Vigilmon and click New Monitor → HTTP.
- Set URL to
https://posthog.yourdomain.com/_health/. - Set Check interval to 60 seconds.
- Set Expected status code to
200. - Under Advanced → Keyword check, add keyword present:
"ok". - Save the monitor.
Vigilmon polls your PostHog health endpoint every minute from multiple regions. A crashed Django process, a Redis failure, or a broken deployment fires an alert before events start dropping.
Step 2: Monitor the Event Ingestion API
PostHog's event ingestion endpoint (/capture/ or /i/v0/e/) is separate from the health check. This is where your SDKs send pageview, custom_event, and identify calls. A Kafka consumer failure, a broken reverse proxy rule, or an overloaded ingestion service can leave this endpoint responding with errors while /_health/ stays green.
Test the ingestion path:
curl -X POST https://posthog.yourdomain.com/capture/ \
-H "Content-Type: application/json" \
-d '{"api_key": "probe-key", "event": "health_probe", "distinct_id": "monitor"}'
The endpoint should return {"status": 1} even for an unknown API key — it accepts and queues the event.
Set up a Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
https://posthog.yourdomain.com/capture/. - Set Method to
POST. - Set Request body to
{"api_key":"probe","event":"health","distinct_id":"vigilmon"}. - Set Content-Type header to
application/json. - Set Expected status code to
200. - Under Advanced → Keyword check, add keyword present:
"status". - Save.
This is the most important monitor for a PostHog deployment. If the ingestion endpoint is down, your entire analytics pipeline is broken even if the UI works fine.
Step 3: Monitor the PostHog Web UI
The PostHog UI (React frontend) lets your team query funnels, cohorts, and dashboards. It's served by Django but relies on a different set of view logic from the API. A bad template deployment or a missing static file can break the UI while the API stays healthy.
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
https://posthog.yourdomain.com/(the PostHog login page). - Set Expected status code to
200. - Under Advanced → Keyword check, add keyword present:
"PostHog". - Save.
Step 4: SSL Certificate Monitoring
PostHog SDKs embedded in your products make HTTPS calls to your PostHog instance. A certificate expiry will cause all SDK calls to fail — not with a visible error in your dashboard, but with silent failures in your users' browsers and mobile apps. You'll lose data with no indication why.
Vigilmon monitors SSL certificates automatically on all HTTPS monitors. Configure expiry alerts:
- Open your PostHog health monitor in Vigilmon.
- Go to Settings → SSL and enable SSL expiry alert.
- Set the warning threshold to 21 days.
- Repeat for the ingestion API monitor.
For analytics platforms, 21 days is the right threshold — you want time to investigate and renew, since any certificate downtime means permanent data loss, not just temporary unavailability.
Step 5: Alert Channels
Go to Notifications → New Channel in Vigilmon and configure:
- Email — your data or product engineering team
- Webhook — post to Slack or PagerDuty
A PostHog ingestion API alert in Slack:
🔴 DOWN: posthog.yourdomain.com/capture/
Status: 503 Service Unavailable
Keyword "status" not found in response
Region: US-West
Started: 2026-01-20 03:14 UTC
Recovery:
✅ RECOVERED: posthog.yourdomain.com/capture/
Downtime: 22 minutes
For the ingestion endpoint specifically, set your alert escalation to immediate — every minute of ingestion downtime means events that can't be recovered.
What You've Built
| Failure scenario | How Vigilmon catches it |
|---|---|
| Django backend crash | /_health/ returns non-200 |
| Redis or PostgreSQL down | /_health/ check fails |
| Kafka ingestion failure | /capture/ monitor returns 5xx |
| Celery worker stopped | Events queue but never process (heartbeat gap) |
| React frontend build broken | Web UI keyword check fails |
| SSL certificate expired | Expiry alert fires 21 days early |
| DNS misconfiguration | All monitors detect resolution failure |
PostHog gives your team full ownership of your product analytics data — but self-hosting means you're responsible for keeping the pipeline running. With Vigilmon watching your health endpoint, ingestion API, UI, and certificates, data loss from silent failures becomes a thing of the past.
Start monitoring your PostHog instance today — register free at vigilmon.online.