Monitoring Blinko with Vigilmon

Blinko is a personal AI-powered notes and bookmarks app with tagging, vector search, and AI-assisted recall — all self-hosted. It runs on TypeScript/Node.js and bundles an embedding service and a vector database alongside the main app. That's more moving parts than a typical notes app, and each one can fail independently. Vigilmon lets you watch every layer — web server, AI embedding pipeline, vector search, database, and file storage — from a single dashboard.

What You'll Set Up

• HTTP uptime monitoring for the web interface (port 3000)
• AI embedding service health check
• Vector search backend availability
• Database connectivity probe
• File attachment storage monitor
• Instant alerts for any failure

Prerequisites

• Blinko running via Docker Compose or direct Node.js on port 3000
• A free Vigilmon account

Why Blinko Monitoring Matters

Blinko is more than a notes app — it's a stack. When any component in that stack fails, the impact varies:

• Web server down — you can't access any notes, bookmarks, or tags
• Embedding service failure — new notes are saved but AI-powered similarity search and recall stop working; you won't notice until you search for something
• Vector search backend unavailable — semantic search returns no results or errors; keyword search may still work but AI features are broken
• Database connectivity lost — all reads and writes fail; the app shows errors or blank pages
• File storage inaccessible — file attachments can't be saved or retrieved; notes with attachments appear broken

Each of these is a different failure mode. Monitoring only the homepage misses most of them.

Step 1: Monitor the Blinko Web Interface

Blinko serves its web UI at port 3000. Add an HTTP uptime monitor to confirm the server is running and responding:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter http://your-blinko-host:3000.
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

If you've set up a reverse proxy (nginx, Caddy, Traefik) in front of Blinko, monitor both the proxy URL and the direct Node.js port. A proxy misconfiguration is a common failure point after upgrades.

Step 2: Monitor the Health Endpoint

Blinko exposes an /api/health endpoint that reports the status of internal services. This is the most valuable monitor you can set up — it gives you a composite status check in a single HTTP probe.

Add a monitor for it:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-blinko-host:3000/api/health
3. Expected status: 200
4. Check interval: 2 minutes
5. Save.

To verify what the endpoint returns, run:

curl http://your-blinko-host:3000/api/health

If Blinko's health endpoint returns a JSON status object, add a body match:

• Expected body contains: "status":"ok" (or whatever the healthy response key is)

This single check will catch database failures, service initialization errors, and backend connectivity issues that the homepage check would miss.

Step 3: Monitor AI Embedding Service Health

Blinko uses an embedding model (typically running as a sidecar service or via an external API) to power semantic search and AI recall. If the embedding service is down, the app continues to function for basic note-taking but AI features silently degrade.

If Blinko runs its own embedding sidecar (e.g., on port 11434 for Ollama, or a custom port):

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-blinko-host:11434 (adjust for your embedding service port).
3. Expected status: 200.
4. Check interval: 5 minutes.
5. Save.

For TCP-level connectivity (faster, no HTTP overhead):

1. Click Add Monitor → TCP.
2. Host: your-blinko-host, Port: 11434.
3. Check interval: 5 minutes.
4. Save.

If you use an external AI provider (OpenAI, Anthropic), monitor the API endpoint reachability at TCP level:

1. Host: api.openai.com, Port: 443.
2. Check interval: 5 minutes.

Step 4: Monitor the Vector Search Backend

Blinko typically uses PGVector (PostgreSQL with the vector extension) or a dedicated vector database like Qdrant for semantic search. A failure here means search returns no results, but the failure is silent — no crash, no error page, just empty results.

If using PGVector (PostgreSQL):

Add a TCP connectivity monitor:

1. Click Add Monitor → TCP.
2. Host: your-blinko-host, Port: 5432.
3. Check interval: 2 minutes.
4. Save.

If using Qdrant:

Qdrant exposes a REST health endpoint:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-blinko-host:6333/healthz.
3. Expected status: 200.
4. Check interval: 2 minutes.
5. Save.

If using Milvus or Weaviate:

Add TCP monitors on their respective default ports (Milvus: 19530, Weaviate: 8080).

Separating the vector backend monitor from the main app monitor lets you distinguish "Blinko is down" from "Blinko is up but search is broken."

Step 5: Monitor Database Connectivity

Blinko uses PostgreSQL for its primary data store. Add a TCP connectivity monitor to confirm the database is accepting connections:

1. Click Add Monitor → TCP.
2. Host: your-blinko-host (or the DB container's IP if containerized separately).
3. Port: 5432.
4. Check interval: 2 minutes.
5. Save.

If Blinko is running via Docker Compose, the database container might not be reachable on a host port. In that case, rely on the /api/health endpoint from Step 2, which should reflect database connectivity internally.

For a deeper check, you can query the database directly from a monitoring script. But for most self-hosters, the health endpoint + TCP port check combination provides sufficient coverage.

Step 6: Monitor File Attachment Storage

Blinko supports file attachments to notes. Attachments are stored either on local disk or in an S3-compatible object store. If the storage backend becomes unavailable or a volume is full, attachments silently fail to save.

For local disk storage: Use a heartbeat that runs a disk space check on a schedule.

Add a lightweight Vigilmon cron heartbeat driven by a cron job on the Blinko host:

# /etc/cron.d/blinko-storage-check
*/10 * * * * root \
  df /path/to/blinko/attachments | awk 'NR==2 {if ($5+0 < 90) exit 0; exit 1}' && \
  curl -s https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_TOKEN

In Vigilmon:

1. Click Add Monitor → Cron Heartbeat.
2. Expected interval: 10 minutes.
3. Copy the heartbeat URL and replace YOUR_HEARTBEAT_TOKEN in the cron script.
4. Save.

If disk usage exceeds 90%, the heartbeat stops pinging and Vigilmon alerts you.

For S3-compatible storage: Add a TCP monitor to your S3 endpoint:

1. Host: s3.amazonaws.com (or your MinIO host), Port: 443.
2. Check interval: 5 minutes.

Step 7: Configure Alert Channels

1. In Vigilmon, go to Alert Channels → Add Channel.
2. Add Slack (paste your incoming webhook URL) or email.
3. For the web interface monitor, set Consecutive failures before alert to 2 to avoid alerts from brief container restarts.
4. For AI and vector search monitors, a single failure is worth knowing about — set to 1.
5. Enable the alert channel on all monitors.

Alert example:

🔴 DOWN: blinko.yourdomain.com/api/health
Status: 503 Service Unavailable
Detected: 2 minutes ago

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web interface | :3000 | Node.js crash, container down | | Health endpoint | /api/health | Internal service failures | | Embedding service | :11434 (or external API) | AI features silently broken | | Vector search | :5432 or :6333 | Semantic search unavailable | | Database | :5432 TCP | All data operations failing | | File storage | Cron heartbeat | Disk full, volume unavailable |

Blinko puts AI-powered note-taking on your own hardware. Vigilmon makes sure all the pieces that power it stay running — so your notes are always there when you need them.

Get started free at vigilmon.online.