Your Redmine server went down at 9 AM on a Monday. The development team couldn't access their sprint backlog, couldn't update tickets, and couldn't see which issues were assigned to them. The first anyone knew was when the project manager emailed asking why the site was unreachable. By then it had been down for 45 minutes and the morning standup had already been derailed.
Redmine is the self-hosted project management and issue tracking system that teams rely on for their daily workflow. It runs on Ruby on Rails, uses a relational database (MySQL, PostgreSQL, or SQLite), and manages a surprising amount of background work — email notifications, repository synchronization, time entry digests. When any part of that stack fails, your team's work coordination stops.
Vigilmon gives you the external monitoring that catches Redmine downtime, background job failures, and email notification issues before they turn into a meeting's worth of firefighting.
What You'll Build
- A Vigilmon HTTP monitor on Redmine's web UI and login page
- A REST API health check on
/issues.json - A background job heartbeat monitor
- SSL certificate expiry alerts
- Alert channels for your team
Prerequisites
- A self-hosted Redmine installation (Redmine 5.x or later recommended)
- API access enabled in Redmine settings
- A free account at vigilmon.online
Step 1: Monitor Web UI Availability
Redmine's homepage is the primary surface your team interacts with. Monitoring it directly catches the broadest class of failures: application crashes, database connectivity issues, Nginx/Apache reverse proxy failures, and out-of-memory kills of the Puma/Passenger/Unicorn process.
- Log in to Vigilmon and click New Monitor → HTTP.
- Set URL to
https://your-redmine.example.com/(your Redmine root URL). - Set Check interval to 60 seconds.
- Set Expected status code to
200. - Under Advanced → Keyword check:
- Keyword present:
Redmineor your project name - Keyword absent:
"Application Error","502 Bad Gateway"
- Keyword present:
- Save the monitor.
Vigilmon checks your Redmine homepage every minute from multiple geographic regions.
Step 2: Login Page Check
Redmine's login page at /login exercises a slightly different code path than the homepage — it verifies that session handling, CSRF token generation, and the authentication system are functional. A broken session store (e.g., a misconfigured Redis or database-backed sessions) can return a valid homepage while breaking logins.
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
https://your-redmine.example.com/login. - Set Check interval to 2 minutes.
- Set Expected status code to
200. - Under Advanced → Keyword check:
- Keyword present:
"Login"or"Username" - Keyword absent:
"error","exception"
- Keyword present:
- Save.
This gives you early warning of authentication system failures before your users' first login attempt of the day.
Step 3: REST API Health Check
Redmine ships with a REST API that integrates with CI/CD systems, Git hooks, time tracking tools, and other project management software. The /issues.json endpoint is a lightweight read that exercises the database, authentication layer, and serialization pipeline.
First, ensure the REST API is enabled in Redmine:
- Go to Administration → Settings → API.
- Enable Enable REST web service.
- Save.
Generate an API key for monitoring (create a dedicated monitoring user with read-only access in Redmine):
# Test the API endpoint
curl -H "X-Redmine-API-Key: <your-api-key>" \
"https://your-redmine.example.com/issues.json?limit=1"
Expected response:
{
"issues": [],
"total_count": 0,
"offset": 0,
"limit": 1
}
A 200 response with a JSON body confirms that Redmine's application server, database, and API serialization layer are all working.
Set up the Vigilmon monitor:
- Click New Monitor → HTTP in Vigilmon.
- Set URL to
https://your-redmine.example.com/issues.json?limit=1. - Set Method to
GET. - Under Advanced → Request headers, add:
- Header:
X-Redmine-API-Key - Value:
<your-monitoring-api-key>
- Header:
- Set Expected status code to
200. - Under Advanced → JSON body assertion, add:
- Path:
total_count - Operator:
exists
- Path:
- Set Check interval to 2 minutes.
- Save.
This monitor catches database failures, application exceptions, and API layer breakage that the homepage check might not surface.
Step 4: Background Job Heartbeat
Redmine relies on background processes for several important functions:
- Email notifications — new issue assignments, status changes, and reply-by-email processing
- Repository synchronization — polling Git/SVN/Mercurial repositories for commits to link to issues
- Time entry reminders — scheduled digest emails for time tracking
- Plugin background tasks — many popular Redmine plugins add their own background jobs
These background tasks are typically run via cron jobs that call Redmine rake tasks (e.g., rake redmine:email:receive_imap). If the cron job fails — due to a permission error, a Ruby version mismatch after an upgrade, or simply a missed restart after a server migration — background processing stops silently while the web UI stays healthy.
Set up a heartbeat monitor in Vigilmon:
- Click New Monitor → Heartbeat in Vigilmon.
- Set the Name to
Redmine Background Jobs. - Set Expected interval to
1 hourwith a30 minutegrace period. - Save and copy the Heartbeat URL.
Configure your Redmine cron job to ping Vigilmon after each run. Edit your crontab:
crontab -e
Add a heartbeat ping after your existing Redmine background job:
# Send Redmine email notifications every hour and ping Vigilmon on success
0 * * * * cd /path/to/redmine && bundle exec rake redmine:emails:send RAILS_ENV=production && curl -fsS https://vigilmon.online/heartbeat/<your-token> > /dev/null 2>&1
For plugin-specific background jobs, chain additional rake tasks before the curl ping. If any rake task fails, the && chain breaks and the heartbeat ping doesn't fire — Vigilmon alerts you that the background processing cycle didn't complete.
Step 5: Email Notification Health
Email notifications are one of Redmine's most-used features — team members rely on issue assignment emails, status change notifications, and @mention alerts to stay informed without watching the UI. Email failures are notoriously silent: Redmine tries to send, ActionMailer queues the message, but if your SMTP server is misconfigured, the mail server is down, or the outbound port is blocked, emails fail without any visible error in the Redmine UI.
The heartbeat monitor in Step 4 partially covers this. For direct email health verification, you can add a Redmine mail receiver test to your cron cycle:
# Test SMTP connectivity (adjust host and port for your setup)
0 6 * * * nc -z your-smtp-server.example.com 587 && curl -fsS https://vigilmon.online/heartbeat/<smtp-health-token> > /dev/null
Create a second heartbeat monitor in Vigilmon named Redmine SMTP with a 24-hour interval and 2-hour grace period. This fires once daily to confirm your SMTP server is reachable.
Step 6: SSL Certificate Alerts
Self-hosted Redmine instances frequently run on custom domains with Let's Encrypt certificates. Certificate expiry is the kind of failure that's completely preventable but still happens regularly — auto-renewal cron jobs fail silently, certbot configurations drift after OS upgrades, and certificate errors surface only when the first user tries to load the site and gets a browser warning.
Vigilmon's HTTPS monitors automatically check certificate validity on every check. Add an explicit expiry alert:
- Open your web UI monitor (from Step 1) in Vigilmon.
- Under Advanced → SSL certificate, enable Alert when certificate expires within and set to
14 days. - Save.
You'll receive an alert 14 days before expiry, giving you time to renew before your team members get browser certificate warnings that block access to their project backlog.
Step 7: Alert Channels
Go to Notifications → New Channel in Vigilmon and set up:
- Email — alerts to your systems administrator and project manager
- Webhook — post to your team's Slack, Discord, or Microsoft Teams channel
A Redmine downtime alert looks like:
🔴 DOWN: your-redmine.example.com
Homepage returned 502 (Bad Gateway)
Region: EU-West
Triggered: 2026-01-15 08:47 UTC
Downtime so far: 3 minutes
A background job heartbeat miss looks like:
🔴 HEARTBEAT MISSED: Redmine Background Jobs
Last ping: 2h 45m ago (expected every 1 hour)
What You've Built
| Scenario | How Vigilmon catches it | |---|---| | Redmine app server crash (Puma/Passenger) | Homepage HTTP monitor detects non-200 | | Database (PostgreSQL/MySQL) unreachable | REST API monitor returns 500/timeout | | Login/session system broken | Login page keyword monitor fails | | Background job cron failure | Heartbeat monitor misses expected ping | | Email notifications silently failing | SMTP heartbeat monitor detects SMTP unreachable | | Reverse proxy (Nginx/Apache) down | HTTP monitor sees 502/504 | | SSL certificate expiry | Certificate alert fires 14 days before expiry | | Repository sync stops | Heartbeat misses ping (cron job broke) |
Redmine is the kind of application your team treats as infrastructure — it's just expected to be there. The moment it isn't, sprint planning, issue triage, and daily standups all start falling apart. A 60-second external health check is the difference between catching a failure in minutes and finding out about it from your project manager.
Start monitoring your Redmine server today — register free at vigilmon.online.