Taiga Monitoring with Vigilmon: Uptime, API Health & Worker Checks for Your Project Management Platform

Your sprint planning session starts in ten minutes. The team opens Taiga to pull up the board — and gets a spinning loader. The backend API is down, the async worker hasn't processed a task in hours, and your SSL certificate expired yesterday. Nobody noticed because there was no external monitor watching.

Taiga is a popular open-source project management platform — a self-hosted alternative to Jira — built on a Django backend, a TypeScript/Angular frontend, and a Celery async worker. Each layer can fail independently. Vigilmon gives you the external uptime monitoring to catch failures across all of them before your team hits them.

This tutorial shows you how to monitor a self-hosted Taiga instance end-to-end.

What You'll Build

• An HTTP monitor on Taiga's API health endpoint
• A web UI availability monitor
• An async task worker heartbeat check
• SSL certificate expiry alerts

Prerequisites

• A self-hosted Taiga instance (Taiga 6.x or newer, Docker or bare-metal)
• A free account at vigilmon.online

Step 1: Monitor the Taiga API Health Endpoint

Taiga's Django backend exposes a health check at /api/v1/. A successful response confirms the API process is running and can serve requests. If Taiga's backend is down or the database is unreachable, this endpoint will fail.

Test it first:

curl -s https://taiga.yourdomain.com/api/v1/ | head -c 200

You should see a JSON response listing available API resources. A 200 status means the backend is healthy.

Set up the Vigilmon monitor:

1. Log in to Vigilmon and click New Monitor → HTTP.
2. Set URL to https://taiga.yourdomain.com/api/v1/.
3. Set Check interval to 60 seconds.
4. Set Expected status code to 200.
5. Under Advanced → Keyword check, add keyword present: "projects" (this key always appears in the API root response).
6. Save the monitor.

Vigilmon now polls your Taiga API every minute from multiple geographic regions. If the Django process crashes, the database goes down, or a bad deployment breaks the API, you'll get an alert before your team reports it.

Step 2: Monitor the Taiga Web UI

The Taiga frontend (Angular/TypeScript SPA) is served separately from the backend API. A misconfigured Nginx reverse proxy, a failed frontend container, or a bad static file deployment can take down the UI while the backend stays healthy — or vice versa.

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://taiga.yourdomain.com/ (your Taiga login page).
3. Set Expected status code to 200.
4. Under Advanced → Keyword check, add keyword present: "Taiga" (appears in the page title and meta tags).
5. Save.

This confirms the full user-facing stack — DNS, TLS, Nginx, and the static file server — is working. If a user can't load the login page, this monitor fires before your helpdesk queue fills up.

Step 3: Detect Async Worker Failures

Taiga uses Celery for async tasks: email notifications, webhooks, project imports/exports, and event processing. If the Celery worker goes down, those tasks silently queue up and never execute. Users stop getting notifications; imports hang indefinitely.

The most reliable way to monitor the worker externally is through an endpoint that exercises it. Taiga's /api/v1/notifications/ endpoint (when authenticated) relies on processed notification events. For external monitoring without credentials, the simplest approach is a project-level webhook integration that fires a test payload to Vigilmon's webhook receiver, or monitoring a known async-dependent page.

For a lightweight check, monitor the events API path that the async worker populates:

1. Click New Monitor → HTTP in Vigilmon.
2. Set URL to https://taiga.yourdomain.com/events/ (Taiga's events WebSocket endpoint responds to HTTP probes with a 200 or 426 Upgrade Required, confirming the events service is alive).
3. Set Expected status codes to 200, 426.
4. Set Check interval to 120 seconds.
5. Save.

Alternatively, if you have a Taiga webhook configured to fire on task completion, route it to a Vigilmon heartbeat URL and alert if no ping arrives within your expected task cycle window.

Step 4: SSL Certificate Monitoring

Self-hosted Taiga instances commonly use Let's Encrypt certificates that must be renewed every 90 days. A missed renewal takes down HTTPS for all users.

Vigilmon monitors SSL certificates automatically on any HTTPS monitor. Check your existing monitors:

1. Go to your Taiga API monitor and click Settings → SSL.
2. Enable SSL expiry alert and set the warning threshold to 14 days.
3. Repeat for the web UI monitor.

You'll receive an alert two weeks before the certificate expires — enough time to run certbot renew or investigate auto-renewal failures before users see TLS errors.

Step 5: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

• Email — alerts to your DevOps or team lead
• Webhook — post to Slack or a PagerDuty incident

A Taiga API-down alert in Slack looks like:

🔴 DOWN: taiga.yourdomain.com/api/v1/
Status: 502 Bad Gateway
Region: EU-West
Started: 2026-01-15 09:42 UTC

When the backend recovers:

✅ RECOVERED: taiga.yourdomain.com/api/v1/
Downtime: 8 minutes

What You've Built

| Failure scenario | How Vigilmon catches it | |---|---| | Django backend crash | API health monitor returns 502/503 | | Database unreachable | API endpoint returns non-200 | | Frontend container down | Web UI monitor fails keyword check | | Nginx misconfiguration | Web UI monitor detects 502 | | Celery worker stopped | Events endpoint monitor / heartbeat gap | | SSL certificate expired | SSL expiry alert fires 14 days early | | DNS misconfiguration | All HTTP monitors detect resolution failure |

Taiga gives your team a powerful self-hosted Jira alternative — but self-hosting means self-monitoring. With Vigilmon watching your API, frontend, workers, and certificates, you'll know about failures before your team's standup turns into a debugging session.

Start monitoring your Taiga instance today — register free at vigilmon.online.