tutorial

Monitoring Your Kanboard Instance with Vigilmon

Set up uptime monitoring, API token health checks, JSON-RPC endpoint verification, SSL certificate alerts, and database connectivity monitoring for your self-hosted Kanboard project management tool.

Monitoring Your Kanboard Instance with Vigilmon

Kanboard is a lean, self-hosted Kanban board for project management. No subscriptions, no data sent to third parties, no vendor lock-in — just your tasks, your server, your rules.

The trade-off is that you own the availability too. When Kanboard goes down during a sprint, your team loses their task board, WIP limits, and automation rules. External monitoring that catches failures before your team notices is the cost of self-hosting done right.

This tutorial covers:

  • Web UI availability
  • API token health check (/api)
  • JSON-RPC endpoint monitoring
  • SSL certificate alerts
  • Database connectivity via response time

Step 1: Understand Kanboard's health signals

Kanboard is a PHP application backed by a database (SQLite, MySQL, or PostgreSQL). Unlike some modern frameworks, it doesn't expose a dedicated /health endpoint. Instead, you monitor it through a combination of:

  1. The web UI — confirms PHP + nginx/Apache are working
  2. The JSON-RPC API — confirms PHP + database connectivity
  3. Response time — a proxy for database query performance

The /api path is Kanboard's JSON-RPC endpoint. Sending a properly authenticated request there gives you a meaningful health signal: a valid response confirms the application is running and can query the database.

Step 2: Set up web UI monitoring in Vigilmon

  1. Sign up at vigilmon.online
  2. Click New Monitor → HTTP
  3. Enter https://kanboard.yourdomain.com/
  4. Set check interval: 1 minute (paid) or 5 minutes (free)
  5. Add a keyword match for Kanboard or Login (text that appears on the login page)
  6. Save

This catches the most common failure modes: PHP process down, nginx misconfiguration, or a failed deployment that left an error page instead of the login form.

Step 3: Monitor the JSON-RPC API endpoint

Kanboard's API at /api uses JSON-RPC 2.0 with token authentication. A successful API call confirms both the PHP application and the database are healthy.

First, get your API credentials from Kanboard:

  1. Log into Kanboard as admin
  2. Go to Profile → API (or https://kanboard.yourdomain.com/user/1/api)
  3. Copy your API token

Create an API health check monitor in Vigilmon:

  1. New Monitor → HTTP
  2. URL: https://kanboard.yourdomain.com/api
  3. Method: POST
  4. Header: Content-Type: application/json
  5. Authentication: Basic auth, username jsonrpc, password = your API token
  6. Body: 
    {"jsonrpc": "2.0", "method": "getVersion", "id": 1}
  7. Keyword match: "result"
  8. Save

The getVersion method is a lightweight read-only call that returns the Kanboard version string. A successful response confirms the PHP application is running, the database is reachable, and API authentication is working.

Example healthy response:

{
  "jsonrpc": "2.0",
  "result": "1.2.x",
  "id": 1
}

If the database is down, Kanboard returns a 200 with an error in the JSON body — the keyword match for "result" (without "error") catches this.

Step 4: Database connectivity via response time

Kanboard stores all data in the database. Slow queries manifest as slow page loads before they cause outright failures. Response time monitoring gives you early warning of database performance problems.

In Vigilmon, on your JSON-RPC API monitor:

  1. Go to the monitor settings
  2. Enable Response time alerts
  3. Set a warning threshold: 2000ms (Kanboard's API should respond in under a second under normal conditions)
  4. Set a critical threshold: 5000ms
  5. Save

Response times creeping from 200ms toward 1s typically indicate:

  • Database table bloat (especially kanboard_actions and kanboard_project_activities)
  • Missing indexes on large tables
  • SQLite lock contention if running SQLite on a busy instance

Set the alert threshold based on your current baseline. Check your Vigilmon response time history graph after a week of normal operation and set the warning at 2× your typical P95 response time.

Step 5: SSL certificate monitoring

A lapsed SSL certificate locks every team member out of the Kanboard UI — browsers refuse to load the page and your task board becomes inaccessible. Self-hosted certificates (especially from Let's Encrypt) have a 90-day validity window, and auto-renewal can silently fail.

In Vigilmon:

  1. Go to New Monitor → SSL Certificate
  2. Enter kanboard.yourdomain.com
  3. Set alert threshold: 30 days before expiry
  4. Save

Add a second SSL monitor if you serve Kanboard on a non-standard port or subdomain:

kanboard.yourdomain.com        # standard
tasks.yourdomain.com           # if you use a different subdomain

Step 6: Optional — monitor the background task runner

Kanboard's automation rules, email notifications, and scheduled tasks run via a background worker. This is typically invoked by cron:

# Run Kanboard background tasks every minute
* * * * * www-data /usr/bin/php /var/www/kanboard/cli cronjob >/dev/null 2>&1

If cron stops running (the cron daemon crashes, the user's crontab is lost after a system update, or the PHP CLI path changes), automation rules stop executing silently.

Add a heartbeat monitor to verify cron is running:

  1. In Vigilmon, click New Monitor → Heartbeat
  2. Set expected interval: 5 minutes
  3. Copy the ping URL

Update your cron job to ping Vigilmon after each successful execution:

* * * * * www-data /usr/bin/php /var/www/kanboard/cli cronjob && curl -fsS "https://vigilmon.online/ping/your-heartbeat-id" >/dev/null 2>&1

Now if the cronjob stops running — for any reason — Vigilmon alerts you within 5 minutes.

Step 7: Alerts via Slack or email

In Vigilmon, go to Notifications → New Channel and configure your preferred notification channel.

Suggested alert routing for a team Kanboard instance:

  • Web UI down → immediate Slack ping to #dev-tools or #ops-alerts
  • API health check failing → immediate alert (database may be down)
  • Response time warning → Slack notification (investigate before it becomes an outage)
  • Cron heartbeat missed → Slack alert (automation rules silently failing)
  • SSL expiry warning → email 30 days out, escalate to Slack at 7 days

Step 8: Status page

For a team-internal Kanboard instance:

  1. Go to Status Pages → New Status Page in Vigilmon
  2. Add your web UI and API monitors
  3. Name it "Project Board Status" or similar
  4. Share the URL in your team's internal wiki or Slack channel description

When someone messages "Kanboard is down," the status page link gives them immediate confirmation rather than making the on-call engineer repeat the same diagnostics each time.

What you've built

| What | How | |------|-----| | Web UI availability | HTTP monitor → / with keyword match | | API token health | HTTP POST monitor → /api with getVersion call | | Database connectivity | Response time alerts on API monitor | | Cron / background tasks | Heartbeat monitor via cron job | | SSL certificate | Vigilmon SSL monitor, 30-day threshold | | Slack/email alerts | Vigilmon notification channels | | Team status page | Vigilmon public status page |

Self-hosted means you own the reliability. Vigilmon makes sure you own the visibility too.

Next steps

  • Add the Kanboard API health check as a step in your deployment pipeline to catch configuration regressions after updates
  • Use Vigilmon's response time history to baseline your database performance before and after schema migrations
  • If you run multiple Kanboard instances (e.g., per team or per project), create monitors for each and group them in a single status page
  • Consider a read-only "monitoring" API user separate from your admin API token, with a distinct token you can rotate without disrupting other API integrations

Get started free at vigilmon.online.

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