How to Monitor LLDAP with Vigilmon (LDAP Port, Web UI, and User Sync Alerts)

LLDAP is a lightweight, self-hosted LDAP server written in Rust. It strips the complexity out of traditional LDAP implementations and gives you a simple directory for authentication — with a clean web UI for user management, a GraphQL API, and first-class integration with tools like Authelia, Nextcloud, Gitea, and Jellyfin. Because it sits at the center of your authentication stack, an LLDAP outage silently breaks login for every app that depends on it.

In this tutorial you'll set up comprehensive monitoring for LLDAP using Vigilmon — free tier, no credit card required.

Why LLDAP needs dedicated monitoring

LLDAP is small and fast, but its failure modes are still significant:

Silent process crash — LLDAP is a single binary. If the process exits unexpectedly, every downstream app attempting LDAP authentication fails with a connection refused error, with no built-in restart unless you've wired up systemd or Docker restart policies
LDAP port unreachable — even if the container is running, the LDAP port (3890) can become unreachable due to firewall changes, network reconfiguration, or port binding conflicts
Web UI failures — the admin UI runs on a separate HTTP port (17170). A crash in the web UI can indicate broader service degradation even when the LDAP interface is still responding
Database corruption or lock — LLDAP uses SQLite by default. Database lock contention or corruption can cause the LDAP query path to return errors while the HTTP UI appears healthy
User sync drift — if LLDAP is the source of truth for user identity, silent sync failures to downstream apps mean users can be added or removed in LLDAP without the change propagating

External monitoring gives you visibility into all three layers: the LDAP protocol, the web interface, and the health API.

What you'll need

A running LLDAP instance (self-hosted, version 0.5.0 or later)
A free Vigilmon account (sign-up takes 30 seconds)
Your LLDAP server's hostname and default ports: 3890 (LDAP), 17170 (web UI / health)

Step 1: Verify the LLDAP health endpoint

LLDAP exposes a /health endpoint on its web UI port (17170 by default). This returns HTTP 200 when the service is running and the database connection is healthy.

Test it:

curl -sf http://your-lldap.example.com:17170/health
# {"status":"healthy"}

If you're exposing LLDAP through a reverse proxy on a standard port, test that path:

curl -sf https://lldap.example.com/health

The health endpoint requires no authentication and is safe to poll externally.

Step 2: Set up HTTP health monitoring in Vigilmon

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the monitor type
Set the URL to your LLDAP health endpoint: http://your-lldap.example.com:17170/health (or your proxy URL)
Set the check interval to 1 minute
Under Expected response, configure:
- Status code: 200
- Response body contains: "healthy"
Save the monitor

Vigilmon will probe this endpoint every minute. If LLDAP crashes, the database locks, or the process hangs, the health endpoint stops responding and an incident opens.

Step 3: Monitor the LDAP port with TCP checks

The /health endpoint tells you the LLDAP process is alive. TCP port monitoring tells you the LDAP interface is reachable — which is what your downstream apps actually connect to.

In Vigilmon, go to Monitors → New Monitor
Choose TCP Port
Enter your LLDAP server hostname: your-lldap.example.com
Enter port: 3890
Set check interval to 1 minute
Save the monitor

If you're using LDAPS (TLS-wrapped LDAP on port 6360), add a second TCP monitor for that port:

Repeat the steps above with port 6360

Having both monitors lets you distinguish between "LLDAP is down entirely" and "LDAP TCP is reachable but returning errors" — two different failure modes requiring different responses.

Step 4: Monitor the web UI separately

LLDAP's admin interface runs on the same port as the health endpoint, but it's worth checking the UI root directly. A misconfiguration or static asset problem can break the admin interface while the /health endpoint stays green.

In Vigilmon, go to Monitors → New Monitor
Choose HTTP / HTTPS
Set the URL to: http://your-lldap.example.com:17170/ (or https://lldap.example.com/)
Set the check interval to 5 minutes (less critical than the LDAP port, but worth tracking)
Under Expected response, configure:
- Status code: 200
Save the monitor

Step 5: Configure alert channels for authentication failures

When LLDAP goes down, you want immediate notification — not a user report that "login is broken." Set up at least one real-time alert channel.

Webhook (Slack, Discord, PagerDuty):

Go to Alert Channels → Add Channel → Webhook
Enter your webhook URL
Assign to all LLDAP monitors

Email:

Go to Alert Channels → Add Channel → Email
Add the on-call or admin email
Assign to all monitors

Configure alert escalation so that if the monitor stays down for more than 5 minutes, a second notification fires to a higher-priority channel. In Vigilmon, you can set this up per monitor under Alert Escalation.

Step 6: Set up user sync verification with heartbeat monitoring

If you run scripts that sync users or groups from LLDAP into downstream systems (Nextcloud, Gitea, Authentik, etc.), those scripts can fail silently. Vigilmon's heartbeat monitors verify that a job ran on schedule.

In Vigilmon, go to Monitors → New Monitor
Choose Heartbeat
Give it a name: "LLDAP user sync"
Set the expected ping interval to match your sync schedule (e.g., 60 minutes)
Save the monitor and copy the ping URL

Add a curl call to the heartbeat URL at the end of your sync script:

#!/bin/bash
# lldap-sync.sh
set -e

# ... your sync logic here ...
ldapsearch -H ldap://localhost:3890 -D "uid=sync_user,ou=people,dc=example,dc=com" \
  -w "$LLDAP_PASS" -b "ou=people,dc=example,dc=com" "(objectClass=person)" cn mail

# Signal successful completion to Vigilmon
curl -sf https://heartbeat.vigilmon.online/ping/your-heartbeat-id

If the script fails before reaching the curl call, or stops running entirely, Vigilmon opens an alert after the expected interval passes.

Step 7: Monitor SSL certificate expiry (if using LDAPS or HTTPS)

If your LLDAP instance uses TLS — either for LDAPS or for the HTTPS web UI behind a reverse proxy — add SSL certificate monitoring to avoid unexpected certificate expiry.

In Vigilmon, go to Monitors → New Monitor
Choose SSL Certificate
Enter your LLDAP domain: lldap.example.com
Set warning threshold to 30 days
Save the monitor

Step 8: Build a status page for your directory infrastructure

A simple internal status page consolidates all your LLDAP health signals into one URL, making it easy for your team to diagnose authentication problems quickly.

In Vigilmon, go to Status Pages → New Status Page
Name it "Directory Services" or "LLDAP Health"
Add your monitors: HTTP health, LDAP TCP, LDAPS TCP (if applicable), web UI, user sync heartbeat, SSL cert
Set the page to internal-only or publish it to your team
Publish the page

Share the URL in your team runbook. When users report login failures, the first check is this page.

Recommended monitor summary

| Monitor | Type | Interval | Checks for | |---|---|---|---| | http://your-lldap:17170/health | HTTP | 1 min | Process and database health | | your-lldap:3890 | TCP | 1 min | LDAP listener availability | | your-lldap:6360 | TCP | 1 min | LDAPS listener (if enabled) | | http://your-lldap:17170/ | HTTP | 5 min | Web UI availability | | LLDAP user sync | Heartbeat | per schedule | Sync job execution | | lldap.example.com | SSL | daily | Certificate expiry |

What's next

Response time baselines — Vigilmon records response times for every HTTP check. Watch for latency increases on the health endpoint that signal database contention before it causes query failures
Multi-instance monitoring — if you're running LLDAP behind a load balancer for high availability, add a direct health check for each backend instance so you can pinpoint which node is sick

Get started free at vigilmon.online — no credit card, your first monitor is live in under a minute.