Your Countly event ingestion pipeline stopped accepting events three hours ago. Your product team is making release decisions based on data from yesterday. The dashboard shows green. The database ran out of connections at 2 AM and nobody got an alert.
Countly is an open-source product analytics and customer data platform built on Node.js. It runs a REST API on port 3001 and a web dashboard on port 6001. Self-hosting Countly means you own the pipeline from SDK instrumentation through event ingestion, aggregation, crash reporting, and push notification delivery — and you own the responsibility of knowing when any part of it fails.
Vigilmon probes your Countly infrastructure from outside, the way a real SDK client would. If the API stops accepting events, if the dashboard goes dark, or if the push service crashes, Vigilmon alerts you before your analytics data has gaps you can't explain.
What You'll Build
- An HTTP monitor on the Countly web dashboard
- An event ingestion pipeline health check
- A push notification service monitor
- A crash reporting processor probe
- A database connectivity check via the management API
- An API rate limit detection monitor
- Alert channels for your analytics operations team
Prerequisites
- A self-hosted Countly installation (v23.x+ recommended)
- API server default port: 3001
- Dashboard default port: 6001
- A free account at vigilmon.online
Step 1: Monitor the Countly Web Dashboard
The Countly web dashboard runs on port 6001 and is the primary interface your product team uses. If it goes down, no one can access reports, funnels, or retention data.
Test the dashboard:
curl -o /dev/null -s -w "%{http_code}" http://your-countly-host:6001/
Expected: a 200 response with the Countly login page or dashboard content.
Set up the Vigilmon monitor:
- Log in to Vigilmon and click New Monitor → HTTP.
- Set URL to
http://your-countly-host:6001/. - Set Check interval to 60 seconds.
- Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword present:
Countly
- Keyword present:
- Save the monitor.
This catches process crashes, port binding failures, and reverse proxy misconfigurations that take the dashboard offline.
Step 2: Monitor the Event Ingestion Pipeline
The event ingestion endpoint at /i on port 3001 is the most critical path in your Countly deployment. Every SDK — web, mobile, server-side — sends data here. If this endpoint fails, your analytics data stops accumulating silently.
Test it with a minimal health probe:
curl -o /dev/null -s -w "%{http_code}" \
"http://your-countly-host:3001/i?app_key=test&device_id=probe&begin_session=1"
Countly responds with {"result":"Success"} on a healthy ingest path — even for unknown app keys in most configurations. The key signal is a 200 response; a 500, 502, or timeout indicates the ingestion pipeline or its backing queue is broken.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-countly-host:3001/i?app_key=probe&device_id=vigilmon-probe&begin_session=1. - Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword present:
result
- Keyword present:
- Set Check interval to 60 seconds.
- Save the monitor.
A failure here means real user events are being dropped right now.
Step 3: Monitor the Push Notification Service
Countly's push notification plugin manages FCM and APNs connections. The management API exposes a health check for plugin status at /o/plugins/drill:
curl -s \
"http://your-countly-host:3001/o/plugins?api_key=YOUR_ADMIN_API_KEY&app_id=YOUR_APP_ID&method=plugin_manager.list" \
| python3 -m json.tool
Alternatively, probe the push delivery endpoint health via Countly's system API:
curl -s \
"http://your-countly-host:3001/o/system?api_key=YOUR_ADMIN_API_KEY&app_id=YOUR_APP_ID&method=healthcheck"
A healthy Countly system API returns {"result": "Success"} when all core plugins, including push, are registered and running.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-countly-host:3001/o/system?api_key=YOUR_ADMIN_API_KEY&app_id=YOUR_APP_ID&method=healthcheck. - Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword present:
Success
- Keyword present:
- Set Check interval to 120 seconds.
- Save the monitor.
Step 4: Monitor the Crash Reporting Processor
Countly's crash reporting processor ingests crash data from mobile SDKs through the /i/crash endpoint. A silent failure here means crash reports are lost and your engineering team has no visibility into production errors.
Test the endpoint accepts data:
curl -s -X POST \
"http://your-countly-host:3001/i/crash?app_key=YOUR_APP_KEY&device_id=probe" \
-d 'crash={"_error":"probe","_nonfatal":true,"_logs":"Vigilmon health check"}'
Expected: {"result":"Success"} with a 200 status code.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-countly-host:3001/i. - Set Method to
GET. - Set Expected status code to
200. - Set Check interval to 180 seconds.
- Save the monitor.
For production setups, send a POST body probe with a known nonfatal crash payload using Vigilmon's Body field under Advanced.
Step 5: Monitor Database Connectivity
Countly stores all analytics data in MongoDB. If the MongoDB connection pool is exhausted or the database host becomes unreachable, Countly's API returns errors even though the Node.js process is still running.
Check database connectivity through the output API:
curl -s "http://your-countly-host:3001/o?api_key=YOUR_ADMIN_API_KEY&app_id=YOUR_APP_ID&method=total_users"
A healthy response returns a JSON object with user count data. A database connectivity failure returns a {"result":"Error"} JSON body or a 500 status code.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-countly-host:3001/o?api_key=YOUR_ADMIN_API_KEY&app_id=YOUR_APP_ID&method=total_users. - Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword absent:
Error
- Keyword absent:
- Set Check interval to 300 seconds.
- Save the monitor.
This monitor catches the case where the API process is alive but can no longer read or write data — one of the most insidious failure modes in analytics platforms.
Step 6: Monitor API Rate Limiting
Countly implements rate limiting to protect the ingestion endpoint from abusive traffic. When the rate limiter misconfigures or becomes overly aggressive, legitimate SDK traffic gets rejected with 429 Too Many Requests responses — your analytics data gaps, silently.
Probe rate limit behavior:
curl -o /dev/null -s -w "%{http_code}" \
"http://your-countly-host:3001/i?app_key=YOUR_APP_KEY&device_id=vigilmon-rate-probe"
Expected: 200. If the response is 429, legitimate events from your users' devices are being blocked.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
http://your-countly-host:3001/i?app_key=YOUR_APP_KEY&device_id=vigilmon-rate-probe. - Set Expected status code to
200. - Under Advanced → Keyword check, add:
- Keyword absent:
429
- Keyword absent:
- Set Check interval to 60 seconds.
- Save the monitor.
Step 7: Alert Channels
Go to Notifications → New Channel in Vigilmon and configure:
- Email — immediate alerts to your data engineering team or analytics ops contact
- Webhook — Slack, Discord, or PagerDuty for team-wide visibility
A failing ingestion pipeline alert in Slack looks like:
🔴 DOWN: countly-event-ingestion (HTTP monitor)
Expected status 200, got 502 Bad Gateway
Region: EU-Central
Triggered: 2026-06-14 03:22 UTC
When the pipeline recovers:
✅ RECOVERED: countly-event-ingestion
Downtime: 47 minutes
Set critical severity for the event ingestion and dashboard monitors — these directly impact product data quality. Use warning severity for the push and crash reporting monitors. Enable Alerting → Escalation to page your on-call engineer if the ingestion endpoint is down for more than 5 minutes; every minute of gap creates unrecoverable data loss.
What You've Built
| Scenario | How Vigilmon catches it |
|---|---|
| Dashboard process crash | HTTP monitor on :6001 fails with connection refused |
| Event ingestion pipeline broken | /i endpoint returns non-200 or times out |
| MongoDB connection pool exhausted | Output API returns Error in JSON body |
| Push notification service crash | Healthcheck endpoint returns non-200 |
| Crash reporting endpoint down | /i/crash POST returns error or connection refused |
| Rate limiter blocking SDK traffic | Ingestion probe receives 429 Too Many Requests |
| Node.js process OOM killed | All monitors fail simultaneously |
Data gaps in your analytics platform are invisible until someone asks a question the data can't answer. External monitoring with Vigilmon gives you a real-time signal when your Countly ingestion pipeline, dashboard, or push service breaks — before a gap becomes an explanation you have to give to your product team.
Start monitoring your Countly server today — register free at vigilmon.online.