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.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter your Tine 2.0 URL:
https://tine.yourdomain.com(orhttp://your-server-ip). - Set Check interval to
1 minute. - Set Expected HTTP status to
200. - Under Keyword check, enter
Tineorloginto verify you're getting the real application, not a stale nginx error page. - 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:
- Type:
HTTP / HTTPS - URL:
https://tine.yourdomain.com/fpm-status(or use a local probe via a cron heartbeat) - Keyword check: Verify the response contains
active processes - 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:
- Type:
TCP - Host: your IMAP server hostname or IP
- Port:
143(IMAP) or993(IMAPS) - Check interval:
2 minutes - 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:
- Type:
HTTP / HTTPS - URL:
https://tine.yourdomain.com/Microsoft-Server-ActiveSync - Expected HTTP status:
401(Z-Push returns 401 for unauthenticated requests — this is correct and means the endpoint is alive) - Check interval:
2 minutes - 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
- Type:
HTTP / HTTPS - URL:
https://tine.yourdomain.com/principals/(or your CalDAV base URL) - Expected HTTP status:
401or207(unauthenticated requests return 401; authenticated returns 207 Multi-Status) - Check interval:
5 minutes
CardDAV Monitor
- Type:
HTTP / HTTPS - URL:
https://tine.yourdomain.com/addressbooks/(or your CardDAV base URL) - Expected HTTP status:
401or207 - 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:
- In Vigilmon, go to Alert Channels and add your preferred notification method: email, Slack, PagerDuty, or webhook.
- 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 |
- 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:
- In Vigilmon, go to Status Pages and click New Status Page.
- 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
- Set a custom domain (e.g.,
status.yourdomain.com) if desired. - 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.