tutorial

Monitoring Double Take with Vigilmon

Double Take is a self-hosted facial recognition server for Frigate NVR — but a crashed Node process, a lagging AI backend, or a stalled recognition queue means your home security system stops identifying people silently. Here's how to monitor every layer with Vigilmon.

Double Take is an open-source self-hosted facial recognition server designed to integrate with Frigate NVR. It receives camera events from Frigate (via MQTT or HTTP webhook), runs faces through a configurable AI backend — CompreFace, DeepStack, CodeProject.AI, or InsightFace — and triggers notifications when a known person is detected. When you self-host it, uptime matters for home security: a crashed Node process, a lagging AI backend, a broken MQTT connection, or a recognition queue backlog means your cameras are capturing events that are never identified. Vigilmon gives you HTTP uptime monitoring, TCP port probes, AI backend latency alerts, and cron heartbeats to keep the full recognition pipeline observable.

What You'll Set Up

  • HTTP uptime monitor for the Double Take web interface (port 3000)
  • AI backend health check (CompreFace, DeepStack, CodeProject.AI, or InsightFace)
  • AI backend response latency monitoring
  • Frigate webhook receiver health check
  • MQTT broker TCP connectivity probe
  • Database health check (SQLite or PostgreSQL)
  • Training data storage accessibility check
  • Recognition queue health heartbeat
  • Notification delivery health check
  • SSL/TLS certificate expiry alert

Prerequisites

  • Double Take running and reachable over HTTP/HTTPS (default port 3000)
  • At least one AI backend configured (CompreFace, DeepStack, CodeProject.AI, or InsightFace)
  • MQTT broker running (if using MQTT mode)
  • A free Vigilmon account

Step 1: Monitor the Double Take Web Interface

The Node.js process serves the web UI, hosts the REST API, and manages the recognition job queue. If it crashes or stops responding, no Frigate events are processed and no identifications occur.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter your Double Take URL: https://doubletake.yourdomain.com (or http://your-server-ip:3000 for a direct install).
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

Double Take also exposes an API health endpoint — check the /api base path or your version's documentation. If a dedicated health route is available, use it instead of the root path for a deeper signal.

Step 2: Monitor AI Backend Health

The AI backend is what actually performs facial recognition. Double Take is a thin orchestration layer — if the backend goes down, Double Take keeps running but every recognition attempt fails silently.

CompreFace:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-compreface-host:8000/api/v1/recognition/faces (or the health endpoint — typically http://your-compreface-host:8000/actuator/health).
  3. Expected HTTP status: 200.
  4. Check interval: 2 minutes.
  5. Click Save.

DeepStack:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-deepstack-host:5000/v1/vision/face/list.
  3. Expected HTTP status: 200.
  4. Check interval: 2 minutes.
  5. Click Save.

CodeProject.AI:

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

InsightFace:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-insightface-host:PORT/health (port varies by deployment).
  3. Expected HTTP status: 200.
  4. Check interval: 2 minutes.
  5. Click Save.

Step 3: Monitor AI Backend Response Latency

Facial recognition latency is critical for real-time identification — if the AI backend takes 10 seconds to respond, Double Take's recognition results arrive after the person has already left the camera frame, and Frigate automations trigger too late.

On whichever AI backend monitor you created in Step 2:

  1. Set a Response time alert threshold: 3000 ms for GPU-accelerated backends (CompreFace, DeepStack with GPU) or 8000 ms for CPU-only backends.
  2. Enable Alert on response time exceeded.
  3. Click Save.

A sustained latency increase often precedes an outright crash — the model is swapping to disk, the GPU VRAM is exhausted, or the container is being throttled. Catching it early lets you restart the container before recognition fails entirely.

Step 4: Monitor the Frigate Webhook Receiver

Double Take receives camera events from Frigate via HTTP webhook. If Double Take's webhook endpoint stops responding, Frigate keeps sending events but none are processed — your camera recognizes motion but never identifies who it is.

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://doubletake.yourdomain.com/api/recognize (the Frigate webhook endpoint — verify the exact path in your Double Take version's documentation).
  3. Set Method to POST.
  4. Expected HTTP status: 200 or 400 — a 400 (bad request, because the monitor sends no valid event body) still confirms the endpoint is alive. A 502 or 504 means the backend has crashed.
  5. Check interval: 5 minutes.
  6. Click Save.

Step 5: Monitor MQTT Broker Connectivity

If your Double Take setup uses MQTT to receive Frigate events (rather than HTTP webhooks), the MQTT broker is a critical dependency. A disconnected broker means Double Take receives no events even if both Frigate and Double Take are running.

  1. Click Add Monitor → TCP Port.
  2. Host: your MQTT broker hostname or IP (Mosquitto, EMQX, etc.).
  3. Port: 1883 (or 8883 for TLS-secured MQTT).
  4. Check interval: 1 minute.
  5. Click Save.

For TLS-secured MQTT on port 8883, you can also add an SSL certificate monitor on the broker's hostname to catch certificate expiry before MQTT clients start rejecting the connection.

Step 6: Monitor Database Health

Double Take stores person profiles, training images metadata, and recognition event history in SQLite (default) or PostgreSQL. A corrupt or inaccessible database means person profiles cannot be loaded and recognition results cannot be saved.

SQLite (default):

SQLite lives on disk alongside the Double Take process — probe it indirectly by checking an API endpoint that queries the database:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: https://doubletake.yourdomain.com/api/people (returns configured person profiles from the database).
  3. Expected HTTP status: 200.
  4. Check interval: 5 minutes.
  5. Click Save.

If the database is inaccessible, this endpoint returns a 500 error.

PostgreSQL (if configured):

  1. Click Add Monitor → TCP Port.
  2. Host: your PostgreSQL server hostname or IP.
  3. Port: 5432.
  4. Check interval: 1 minute.
  5. Click Save.

Step 7: Monitor Training Data Storage

Double Take stores training images (the photos of known people) on disk. If the storage volume becomes unmounted, fills up, or its permissions change, new training is blocked and existing recognition quality degrades as the model cannot be re-trained.

Probe the training data path indirectly via the people API:

  1. The /api/people monitor from Step 6 also validates that person profile images are accessible — a healthy 200 response with populated data confirms both database and file storage are working.
  2. Add a disk space cron heartbeat if Double Take runs on a host with limited storage:
#!/bin/bash
# /etc/cron.d/doubletake-disk-check
*/15 * * * * root \
  AVAIL=$(df /opt/double-take/storage --output=avail | tail -1); \
  [ "$AVAIL" -gt 524288 ] && curl -s https://vigilmon.online/heartbeat/YOUR_DISK_TOKEN

This pings Vigilmon every 15 minutes only when more than 512 MB is available. If the ping goes silent, disk space is critically low and new training images will fail to save.

Step 8: Recognition Queue Health

Double Take processes incoming Frigate events in a queue. If the queue backs up — due to a slow AI backend, too many simultaneous camera events, or resource exhaustion — recognition lag increases until events are processed minutes after the person left the frame.

Add a cron heartbeat that monitors queue throughput:

  1. In Vigilmon, click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 5 minutes.
  3. Copy the heartbeat URL.
  4. Add a script that pings the heartbeat only when the recognition API responds within your latency threshold:
#!/bin/bash
START=$(date +%s%N)
STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/api/recognize -X POST)
END=$(date +%s%N)
LATENCY=$(( (END - START) / 1000000 ))

# Only ping if response was healthy and under 5 seconds
if [ "$STATUS" -lt 500 ] && [ "$LATENCY" -lt 5000 ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_QUEUE_TOKEN
fi

Run this via cron every 5 minutes. Silence means either the API is down or recognition is too slow to be useful.

Step 9: Notification Delivery Health

Double Take sends alerts via Home Assistant, SMTP, or Slack when a known person is recognized. If notification delivery breaks, your home automation flows and security alerts stop working even though recognition is functioning.

For webhook-based notifications (Home Assistant):

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: your Home Assistant webhook URL (the one Double Take calls on recognition events).
  3. Expected HTTP status: 200.
  4. Check interval: 10 minutes.
  5. Click Save.

This confirms Home Assistant's webhook endpoint is reachable from Double Take's host — if it returns a connection error, Double Take's recognition notifications are being silently dropped.

Step 10: SSL/TLS Certificate Expiry

Double Take is often accessed by Frigate (for webhook delivery) and by your home automation stack (for API queries). A lapsed certificate on the Double Take endpoint breaks Frigate's webhook delivery without any visible error in the UI.

  1. Open the HTTP monitor created in Step 1.
  2. Enable Monitor SSL certificate.
  3. Set Alert when certificate expires in less than 21 days.
  4. Click Save.

Step 11: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
  2. Set Consecutive failures before alert to 2 on the web interface monitor — a single slow check is noise.
  3. Route AI backend health, MQTT broker, and queue heartbeat alerts to a higher-urgency channel — these failures silently break recognition for all cameras simultaneously.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP — web interface | https://doubletake.yourdomain.com | Node.js crash, port 3000 not listening | | HTTP — AI backend health | CompreFace/DeepStack/CodeProject.AI/InsightFace | Recognition backend down | | HTTP — AI backend latency | AI backend endpoint | GPU/CPU exhaustion, model swap | | HTTP — Frigate webhook | /api/recognize | Webhook receiver broken, events not processed | | TCP — MQTT broker | :1883 | Broker down, no events received from Frigate | | HTTP — people API | /api/people | Database or file storage inaccessible | | TCP — PostgreSQL | :5432 | Database (if PostgreSQL) unreachable | | Cron heartbeat — disk | disk space check script | Training image storage full | | Cron heartbeat — queue | recognition latency script | Queue backlog, recognition lag | | HTTP — HA webhook | Home Assistant endpoint | Notification delivery broken | | SSL certificate | Double Take domain | TLS renewal failure |

Self-hosting Double Take means owning the entire facial recognition pipeline — from the MQTT event bus to the AI model inference to the notification delivery. With Vigilmon watching every layer, you catch a crashed AI backend before your cameras stop identifying anyone, a full disk before training breaks, and a broken MQTT connection before Frigate events are silently dropped.

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