tutorial

Monitoring Tine 2.0 with Vigilmon

Tine 2.0 is a powerful open source groupware suite — here's how to monitor its PHP application, MySQL database, Redis session store, IMAP integration, ActiveSync endpoint, CalDAV/CardDAV, and background job queue with Vigilmon.

Tine 2.0 is an enterprise-grade open source groupware platform — email, calendar, contacts, CRM, time tracking, and HR management in a single PHP application. Self-hosting Tine 2.0 means running a multi-service stack: the PHP application behind Apache or Nginx + PHP-FPM, MySQL or MariaDB for groupware data, Redis for sessions and caching, an external IMAP server for email, and optionally RabbitMQ for async jobs and Elasticsearch for full-text search. A failure in any layer — a saturated PHP-FPM pool, a Redis session store outage, or a stale IMAP connection — silently breaks collaboration for every user. Vigilmon gives you end-to-end visibility across the entire Tine 2.0 stack.

What You'll Set Up

  • HTTP uptime monitor for the Tine 2.0 web UI
  • PHP-FPM pool saturation alert via status endpoint
  • MySQL/MariaDB database connectivity monitor
  • Redis session and cache layer health check
  • IMAP server connectivity monitor
  • ActiveSync (Z-Push) endpoint health check
  • CalDAV/CardDAV endpoint monitors for mobile sync
  • Background job queue depth alert via cron heartbeat
  • Alert channels with appropriate thresholds

Prerequisites

  • Tine 2.0 installed and accessible via HTTP/HTTPS
  • PHP-FPM status page enabled (see Step 2)
  • A free Vigilmon account

Step 1: Monitor the Tine 2.0 Web Application

The Tine 2.0 PHP application is the core of your groupware stack. An HTTP monitor on the login page or a dedicated health endpoint catches PHP crashes, misconfigured sessions, and database connectivity failures.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter your Tine 2.0 URL: https://tine.yourdomain.com (or http://your-server-ip).
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Under Keyword check, enter Tine or login to verify you're getting the real application, not a stale nginx error page.
  7. Click Save.

If you have a custom health endpoint configured in your Tine 2.0 instance, use that instead. The login page check is a reliable fallback because it exercises the PHP runtime, session layer, and database connection in a single request.


Step 2: Monitor PHP-FPM Pool Saturation

When PHP-FPM runs out of worker processes, Tine 2.0 returns 502 errors and users experience hanging requests. The PHP-FPM status page exposes real-time worker counts — use a Vigilmon keyword monitor to alert before the pool is fully saturated.

First, enable the PHP-FPM status page in your pool configuration (typically /etc/php/8.x/fpm/pool.d/www.conf):

pm.status_path = /status

Expose it via Nginx with an internal-only location block:

location /fpm-status {
    access_log off;
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

Then add a Vigilmon monitor:

  1. Type: HTTP / HTTPS
  2. URL: https://tine.yourdomain.com/fpm-status (or use a local probe via a cron heartbeat)
  3. Keyword check: Verify the response contains active processes
  4. Check interval: 1 minute

For a saturation alert, create a script that parses the FPM status and sends a heartbeat to Vigilmon only when workers are under threshold:

#!/bin/bash
STATUS=$(curl -s http://127.0.0.1/fpm-status)
ACTIVE=$(echo "$STATUS" | grep "active processes" | awk '{print $NF}')
MAX=$(echo "$STATUS" | grep "max children reached" | awk '{print $NF}')
PM_MAX=$(php-fpm8.2 -tt 2>&1 | grep "^pm.max_children" | awk '{print $NF}')

THRESHOLD=$(echo "$PM_MAX * 0.85" | bc | cut -d. -f1)

if [ "$ACTIVE" -lt "$THRESHOLD" ]; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_HEARTBEAT_SLUG" > /dev/null
fi

Add to crontab:

* * * * * /usr/local/bin/check-fpm.sh

Create the heartbeat in Vigilmon with a 1.5-minute grace period — if it misses one beat, PHP-FPM workers are above 85% and you get an alert.


Step 3: Monitor MySQL/MariaDB

All Tine 2.0 groupware data — calendar events, contacts, CRM records, email metadata, and time tracking — lives in MySQL. A database outage means zero functionality.

Create a monitoring user in MySQL:

CREATE USER 'vigilmon'@'localhost' IDENTIFIED BY 'strong-password-here';
GRANT SELECT ON tine20.* TO 'vigilmon'@'localhost';
FLUSH PRIVILEGES;

Add a health check script:

#!/bin/bash
RESULT=$(mysql -u vigilmon -pstrong-password-here -h 127.0.0.1 tine20 \
  -e "SELECT 1" 2>&1)

if echo "$RESULT" | grep -q "1"; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_DB_HEARTBEAT" > /dev/null
fi

Schedule it every minute:

* * * * * /usr/local/bin/check-tine-db.sh

Create the heartbeat in Vigilmon with a 2-minute grace period. You can extend this script to also check slow query count:

SLOW=$(mysql -u vigilmon -pstrong-password-here -e \
  "SHOW GLOBAL STATUS LIKE 'Slow_queries'" | awk '/Slow_queries/{print $2}')

Alert if the slow query count grows by more than 10 per minute, which indicates missing indexes on large CRM or time tracking tables.


Step 4: Monitor Redis

Tine 2.0 uses Redis for session management and caching. If Redis goes down, users are immediately logged out and session state is lost. A ping monitor is the simplest early warning.

Create a Redis check script:

#!/bin/bash
PONG=$(redis-cli -h 127.0.0.1 -p 6379 PING 2>/dev/null)

if [ "$PONG" = "PONG" ]; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_REDIS_HEARTBEAT" > /dev/null
fi

Add to crontab:

* * * * * /usr/local/bin/check-redis.sh

Create the heartbeat in Vigilmon with a 2-minute grace period. You can enrich the check with memory usage:

USED_MB=$(redis-cli -h 127.0.0.1 INFO memory | grep "used_memory:" | awk -F: '{print $2}' | tr -d '\r')
MAX_MB=$(redis-cli -h 127.0.0.1 CONFIG GET maxmemory | tail -1)

Alert if Redis memory usage exceeds 85% of maxmemory — at that point Redis starts evicting keys that Tine 2.0 sessions depend on.


Step 5: Monitor IMAP Server Connectivity

Tine 2.0 does not store emails itself — it fetches them from an external IMAP server (Dovecot, Cyrus IMAP, or a hosted service). If the IMAP connection fails, users cannot access their email in the Tine 2.0 webmail interface.

Use a TCP monitor in Vigilmon to check IMAP port availability:

  1. Type: TCP
  2. Host: your IMAP server hostname or IP
  3. Port: 143 (IMAP) or 993 (IMAPS)
  4. Check interval: 2 minutes
  5. Click Save.

For a deeper check that verifies IMAP login, use a heartbeat with an authentication script:

#!/bin/bash
RESULT=$(curl -s --max-time 10 \
  --url "imaps://mail.yourdomain.com" \
  --user "monitoruser@yourdomain.com:monitorpassword" \
  -X "EXAMINE INBOX" 2>&1)

if echo "$RESULT" | grep -q "OK"; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_IMAP_HEARTBEAT" > /dev/null
fi

An IMAP login check is more reliable than a raw TCP check because it verifies authentication, TLS negotiation, and the mailbox backend — the same path Tine 2.0 uses for every user.


Step 6: Monitor the ActiveSync (Z-Push) Endpoint

Tine 2.0 supports Exchange ActiveSync for mobile device sync via Z-Push. If the Z-Push endpoint fails, mobile calendar, contacts, and email sync breaks silently for all connected devices.

Add a Vigilmon HTTP monitor targeting the Z-Push endpoint:

  1. Type: HTTP / HTTPS
  2. URL: https://tine.yourdomain.com/Microsoft-Server-ActiveSync
  3. Expected HTTP status: 401 (Z-Push returns 401 for unauthenticated requests — this is correct and means the endpoint is alive)
  4. Check interval: 2 minutes
  5. Click Save.

A 401 response from Z-Push means the PHP application and the ActiveSync router are functioning. A 502 or 503 means PHP-FPM or the Tine 2.0 application has failed.


Step 7: Monitor CalDAV and CardDAV Endpoints

Tine 2.0 exposes CalDAV for calendar sync and CardDAV for contact sync. These endpoints are used by iOS, macOS, and third-party calendar apps. Monitor them independently from the main web UI because CalDAV/CardDAV are often served under a different path or subdomain.

CalDAV Monitor

  1. Type: HTTP / HTTPS
  2. URL: https://tine.yourdomain.com/principals/ (or your CalDAV base URL)
  3. Expected HTTP status: 401 or 207 (unauthenticated requests return 401; authenticated returns 207 Multi-Status)
  4. Check interval: 5 minutes

CardDAV Monitor

  1. Type: HTTP / HTTPS
  2. URL: https://tine.yourdomain.com/addressbooks/ (or your CardDAV base URL)
  3. Expected HTTP status: 401 or 207
  4. Check interval: 5 minutes

If your Tine 2.0 instance serves CalDAV and CardDAV on a separate subdomain (e.g., caldav.yourdomain.com), add separate monitors for each subdomain.


Step 8: Monitor Background Job Queue Depth

Tine 2.0 runs asynchronous jobs for email sync, calendar reminders, and notifications. If the background worker stops processing jobs, the queue grows and users experience delayed notifications and stale email sync. Use a heartbeat monitor that checks the queue depth via the Tine 2.0 database:

#!/bin/bash
QUEUE_DEPTH=$(mysql -u vigilmon -pstrong-password-here tine20 \
  -sN -e "SELECT COUNT(*) FROM tine_async_jobs WHERE status = 'running' OR status = 'pending'")

# Alert if queue depth is above 500 jobs (tune for your workload)
if [ "$QUEUE_DEPTH" -lt 500 ]; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_QUEUE_HEARTBEAT" > /dev/null
fi
*/5 * * * * /usr/local/bin/check-tine-queue.sh

Create the heartbeat in Vigilmon with a 6-minute grace period. A queue that's not draining — indicated by the heartbeat going silent — means background workers have stopped, and email sync will fall behind.


Step 9: Configure Alert Channels

Set up alert routing in Vigilmon so the right team is notified for each failure type:

  1. In Vigilmon, go to Alert Channels and add your preferred notification method: email, Slack, PagerDuty, or webhook.
  2. Apply the following alert thresholds to each monitor:

| Monitor | Alert After | Severity | |---|---|---| | Tine 2.0 web UI | 2 consecutive failures (2 min) | Critical | | PHP-FPM saturation heartbeat | 1 missed beat | Warning | | MySQL heartbeat | 1 missed beat | Critical | | Redis heartbeat | 1 missed beat | Critical | | IMAP TCP / login | 3 consecutive failures (6 min) | High | | ActiveSync endpoint | 3 consecutive failures | High | | CalDAV/CardDAV | 3 consecutive failures | High | | Job queue heartbeat | 1 missed beat | Warning |

  1. For critical monitors (web UI, MySQL, Redis), enable escalation — send a second alert to an on-call channel or PagerDuty if the failure lasts more than 10 minutes without acknowledgement.

Step 10: Create a Status Page

Give your users a transparent view of groupware health with a Vigilmon public status page:

  1. In Vigilmon, go to Status Pages and click New Status Page.
  2. Add all your Tine 2.0 monitors grouped by service:
    • Web Application: Tine 2.0 web UI, PHP-FPM
    • Data Layer: MySQL, Redis
    • Communication: IMAP, ActiveSync, CalDAV, CardDAV
    • Background Jobs: Job queue heartbeat
  3. Set a custom domain (e.g., status.yourdomain.com) if desired.
  4. Share the URL with your users so they can check service health during incidents.

Why Monitoring Tine 2.0 Matters

Tine 2.0 powers enterprise collaboration — missed emails, stale calendars, or inaccessible CRM records have direct business impact. The risks fall into three categories:

Silent degradation: PHP-FPM pool saturation causes intermittent 502 errors that users report as "the site is slow" rather than "the site is down." By the time 100% of workers are busy, the incident has been ongoing for minutes. A saturation alert at 85% gives you response time before users are affected.

Session loss: Redis failure evicts session tokens and logs out every active user simultaneously. For an enterprise groupware platform, this is a high-impact event that may not be immediately obvious from the web UI monitor alone. A dedicated Redis heartbeat gives you the earliest possible warning.

Mobile sync blindness: ActiveSync and CalDAV/CardDAV failures don't produce visible errors in the web UI — they only show up on mobile devices as sync errors. Without endpoint-specific monitors, you have no visibility into whether mobile sync is functioning.

Vigilmon covers all three failure modes with the setup above, giving you confidence that Tine 2.0 is delivering its full collaboration functionality — not just responding to HTTP requests.


Ready to monitor your Tine 2.0 instance? Create a free Vigilmon account and have all monitors running in under 15 minutes.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →