How to Monitor Twenty CRM with Vigilmon

Twenty is a modern, open-source CRM platform designed for teams that want full control over their customer data. When you self-host Twenty, you're also responsible for keeping it available — because a CRM outage means your sales team can't access contact records, pipelines go stale, and customer interactions fall through the cracks.

This tutorial walks you through setting up robust monitoring for a self-hosted Twenty installation using Vigilmon, so you catch issues before they affect your team.

Why monitoring Twenty matters

Twenty is a full-stack application with multiple moving parts: a GraphQL API backend, a React frontend, background jobs, and a PostgreSQL database. Each of these can fail independently, and not all failures are visible to end users until it's too late:

• API downtime — the GraphQL endpoint stops responding, breaking all CRUD operations while the frontend may still load a cached shell
• Database connectivity loss — Twenty's backend loses its PostgreSQL connection; writes silently fail or return unhelpful 500 errors
• Metadata sync failures — Twenty's object metadata layer gets out of sync, causing custom field definitions to disappear or return stale data
• Background worker stoppage — email notifications, automation triggers, and data sync jobs stop running without any visible indicator in the UI
• Frontend build failures — after an upgrade, the React app fails to load, presenting users with a blank screen

External monitoring catches all of these from the perspective that matters most: can your team actually use the CRM right now?

What you'll need

• A running self-hosted Twenty instance (Docker Compose or Kubernetes)
• A free Vigilmon account — no credit card required

Step 1: Identify Twenty's health endpoints

Twenty exposes several endpoints suitable for monitoring:

| Endpoint | Purpose | |----------|---------| | /healthz | Backend health check — confirms API server is running | | /api/health | Detailed health check including DB connectivity | | / | Frontend root — confirms the React app is serving | | /api | GraphQL playground root — confirms API routing works |

The /healthz endpoint is the primary uptime check: it's lightweight, unauthenticated, and returns HTTP 200 when the backend is healthy.

Step 2: Set up HTTP monitoring in Vigilmon

Monitor 1: Backend health check

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS
3. Set the URL to:

   https://your-twenty-domain.com/healthz
   

4. Check interval: 1 minute
5. Expected status code: 200
6. Save the monitor

Monitor 2: API endpoint availability

1. Create a second HTTP / HTTPS monitor
2. URL:

   https://your-twenty-domain.com/api/health
   

3. Expected status code: 200
4. Check interval: 2 minutes

This endpoint performs a deeper health check that includes database connectivity. If the API returns 200 but the database check fails, this monitor will catch it.

Monitor 3: Frontend availability

1. Create a third HTTP / HTTPS monitor
2. URL:

   https://your-twenty-domain.com/
   

3. Expected status code: 200
4. (Optional) Response body contains: Twenty or your custom title
5. Check interval: 5 minutes

The frontend check verifies that the React application is being served correctly. After upgrades, build failures can cause the frontend to return a blank page or a build error — this check will catch those regressions.

Monitor 4: GraphQL API routing

1. Create a fourth HTTP / HTTPS monitor
2. URL:

   https://your-twenty-domain.com/api
   

3. Expected status code: 200
4. Check interval: 5 minutes

Step 3: Set up TCP port monitoring

Verify that Twenty's backend port is reachable at the network level, independently of HTTP-level application checks.

1. Go to Monitors → New Monitor in Vigilmon
2. Choose TCP Port
3. Enter:
   • Host: your-twenty-domain.com
   • Port: 443 (if behind a TLS proxy)
   • Or port 3000 (Twenty's default backend port) if directly accessible
4. Check interval: 1 minute
5. Save the monitor

If you're running Twenty with Docker Compose and your reverse proxy is nginx or Caddy, add a separate TCP check for port 80 to catch proxy-level certificate or redirect failures.

Step 4: Configure your Docker Compose deployment with health checks

If you're running Twenty with Docker Compose, add built-in health checks to catch container-level failures:

version: "3.9"

services:
  server:
    image: twentycrm/twenty:latest
    ports:
      - "3000:3000"
    environment:
      SERVER_URL: https://your-twenty-domain.com
      FRONT_BASE_URL: https://your-twenty-domain.com
      PG_DATABASE_URL: postgres://twenty:${PG_PASSWORD}@db:5432/twenty
      APP_SECRET: ${APP_SECRET}
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s
    restart: unless-stopped

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: twenty
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: twenty
    volumes:
      - twenty_db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U twenty"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  worker:
    image: twentycrm/twenty:latest
    command: ["node", "dist/src/queue-worker/queue-worker.js"]
    environment:
      PG_DATABASE_URL: postgres://twenty:${PG_PASSWORD}@db:5432/twenty
      APP_SECRET: ${APP_SECRET}
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

volumes:
  twenty_db:

The healthcheck directives help Docker restart unhealthy containers, while Vigilmon alerts you that a restart happened and how long the outage lasted.

Step 5: Monitor the metadata sync endpoint

Twenty's metadata sync is a critical background operation that keeps your CRM's schema consistent. If it falls behind or errors, custom objects and fields can behave unexpectedly.

You can create a synthetic check that calls the metadata endpoint:

1. Create an HTTP / HTTPS monitor
2. URL:

   https://your-twenty-domain.com/api/metadata
   

3. Method: GET
4. Expected status code: 200 (unauthenticated metadata introspection returns schema info)
5. Check interval: 10 minutes

If your Twenty instance requires authentication for all API routes, configure HTTP authentication in Vigilmon's monitor settings with a service account token. Use an API key from a dedicated monitoring user rather than a personal admin account.

Step 6: Configure alert channels

1. In Vigilmon, go to Alert Channels → Add Channel
2. Add your preferred channels:
   • Slack — route backend health alerts to your #engineering channel
   • Email — for the sales/ops team lead who owns the CRM
   • PagerDuty — if Twenty is customer-facing and downtime is business-critical

For a CRM, we recommend two alert tiers:

• Tier 1 (immediate): /healthz or /api/health failures → Slack + on-call pager
• Tier 2 (non-urgent): Frontend or metadata failures → Slack notification + email during business hours

Step 7: Set up a status page

If multiple teams use Twenty, a status page reduces support noise when the CRM is down.

1. Go to Status Pages → New Status Page
2. Add monitors: "CRM API", "CRM Frontend", "Database Connectivity"
3. Publish and share the URL with your team

Post the status page URL in your team's internal wiki so people know where to check before filing IT tickets.

Complete monitor setup summary

| Monitor | Type | Target | Interval | Catches | |---------|------|--------|----------|---------| | Backend health | HTTP | /healthz | 1 min | Server crash, OOM, startup failure | | API + DB health | HTTP | /api/health | 2 min | Database connectivity loss | | Frontend | HTTP | / | 5 min | Build failures, static asset errors | | GraphQL API | HTTP | /api | 5 min | API routing failures | | Metadata sync | HTTP | /api/metadata | 10 min | Schema sync errors | | HTTPS port | TCP | :443 | 1 min | Reverse proxy failures |

Conclusion

Self-hosting Twenty gives you data sovereignty and customization control that SaaS CRMs can't match — but it also puts operational responsibility in your hands. A few minutes of downtime means your sales team is flying blind.

With Vigilmon monitoring your Twenty deployment, you'll know about every outage, restart, or degradation within 60 seconds — before your users notice. Set up the monitors once, configure your alert channels, and get back to focusing on your product.

Start monitoring for free at vigilmon.online.