Server Watchdog

Monitor remote servers via SSH — check service health (PM2, systemd, Docker), database status (MongoDB, MySQL, PostgreSQL), disk space, memory, and auto-rest...

Security Scan

The skill's public description promises a general multi-OS, multi-service server watchdog, but the bundled instructions and code are narrowly targeted (Windows MongoDB), implicitly require SSH passwords / Telegram tokens that are not declared, and include hard-coded environment-specific values — the pieces don't add up and deserve caution.

Purpose & Capability

The skill claims broad monitoring (PM2, systemd, Docker, MongoDB/MySQL/Postgres, cross-OS) but the included executable (scripts/mongodb-watchdog.js) only implements a Windows-focused MongoDB watchdog (net stop/start, Windows log paths, D: drive path, default chatId, mentions 10.0.0.213). This mismatch suggests either the package is incomplete/partial or mislabeled.

Instruction Scope

SKILL.md instructs the agent/user to perform SSH operations (including password-based SSH via expect) and to copy and run the included Node script on targets. It instructs reading remote logs, restarting services, and embedding passwords into expect/ssh commands — actions that expose credentials and have broad system impact. The instructions do not declare or constrain where alert credentials (Telegram token) come from but the script will attempt to use them.

Install Mechanism

There is no install spec (instruction-only), which reduces installation risk on the agent host. However the SKILL.md explicitly instructs copying the JS file to remote servers and running npm/pm2 there — this writes a persistent process and files on target machines. That remote persistence is part of the skill's behavior and should be considered when granting access.

Credentials

Registry metadata declares no required env vars or credentials, yet the script reads process.env.TELEGRAM_BOT_TOKEN and process.env.TELEGRAM_CHAT_ID and falls back to a hard-coded chatId. SKILL.md also assumes SSH credentials (passwords or keys) but doesn't declare how these should be provided. Requiring passwords via expect is disproportionate and insecure compared to using SSH keys or documented credential fields.

Persistence & Privilege

The skill does not request 'always' or elevated platform privileges, but it instructs deploying a persistent pm2-managed service on remote hosts and writing logs to specified filesystem paths (e.g., D:\ProPower_System\logs). That gives the skill ongoing presence on any server where it's installed — acceptable for monitoring but important to review and restrict.

What to consider before installing

This package is inconsistent and should be reviewed carefully before use. Key concerns: (1) the code is Windows/MongoDB-specific despite a broad multi-service description — don’t assume it will safely monitor Linux/other services; (2) the script expects TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID but the skill metadata doesn't declare these — if you provide a bot token, the script will send messages to Telegram; (3) SKILL.md recommends using expect to pass SSH passwords on the command line — avoid this: prefer SSH key-based auth or an audited secrets mechanism; (4) the script contains hard-coded, environment-specific values (default chatId, an IP/username in alert text, Windows log and D: paths) that may leak or expose sensitive infrastructure details or mislead operators; (5) the workflow instructs copying and running the JS with pm2 on production servers, creating persistent processes and local logs — test in a sandbox first. Recommended actions before installing: (A) run the JS in a controlled test environment and read the full file; (B) replace expect/password-based SSH steps with key-based SSH; (C) set and verify Telegram tokens/chat IDs in a safe way (and remove hard-coded defaults); (D) confirm file paths and service names match your environment, and remove or adjust hard-coded IP/username references; (E) review filesystem write locations and permissions to avoid unexpected writes; (F) if you need cross-platform/multi-service monitoring, request or inspect the full implementation for those other services rather than assuming this skill covers them. If the publisher provides a version that actually supports the broader set of services and declares required credentials, re-evaluate with that package.

Monitor and auto-heal remote servers via SSH. Check services, databases, disk, memory — restart what's down, alert what's wrong.

Prerequisites

• SSH access to target server (password or key-based)
• expect available locally (for password-based SSH)
• Target server runs PM2, systemd, or Docker for service management

Quick Reference

Check PM2 services

ssh user@host "pm2 list"
ssh user@host "pm2 logs --lines 20 --nostream"

Check MongoDB

# Windows
ssh user@host "net start | findstr MongoDB"
ssh user@host "powershell -Command \"(Test-NetConnection -ComputerName 127.0.0.1 -Port 27017).TcpTestSucceeded\""

# Linux
ssh user@host "systemctl status mongod"
ssh user@host "mongosh --eval 'db.runCommand({ping:1})' --quiet"

Check disk & memory

# Linux
ssh user@host "df -h && free -h"

# Windows
ssh user@host "powershell -Command \"Get-PSDrive -PSProvider FileSystem | Select Root,Used,Free; \$os=Get-CimInstance Win32_OperatingSystem; Write-Output ('RAM: '+[math]::Round((\$os.TotalVisibleMemorySize-\$os.FreePhysicalMemory)/1MB,1)+'GB / '+[math]::Round(\$os.TotalVisibleMemorySize/1MB,1)+'GB')\""

Workflow

1. Diagnose — SSH in, check service status, logs, disk, memory
2. Identify — Parse logs for errors, crashes, OOM, or unclean shutdowns
3. Fix — Restart crashed services (pm2 restart, net start, systemctl restart)
4. Verify — Confirm service is back up and responding
5. Alert — Notify user via messaging with summary

Crash Analysis

When a service is down, check these in order:

1. Service logs — pm2 logs, journalctl -u service, Windows Event Log
2. Application logs — Check log files at configured paths
3. System events — OOM killer, unexpected shutdowns, disk full
4. Database logs — MongoDB: check mongod.log for Fatal ("s":"F") entries

MongoDB crash patterns

"s":"F" — Fatal error (crash)
"Unhandled exception" — Internal bug (often FTDC related)
"Detected unclean shutdown" — Process killed without graceful shutdown
"WiredTiger error" — Storage engine corruption

Auto-Heal Recipes

PM2 service restart

pm2 restart <service-name>
pm2 save  # persist across reboots

MongoDB (Windows)

net stop MongoDB
timeout /t 5
net start MongoDB

MongoDB (Linux)

sudo systemctl restart mongod

Deploy watchdog service

For persistent monitoring, deploy the included watchdog script:

1. Copy scripts/mongodb-watchdog.js to target server
2. Install: npm init -y && npm install mongodb
3. Start: pm2 start mongodb-watchdog.js --name mongodb-watchdog
4. Save: pm2 save

SSH with password (via expect)

When key-based auth isn't available:

expect -c 'set timeout 20
spawn ssh -o StrictHostKeyChecking=no user@host "COMMAND"
expect {
    "password:" { send "PASSWORD\r"; exp_continue }
    eof
}
'

Alert Template

🚨 Server Alert — [hostname]

⏰ Time: [timestamp]
❌ Issue: [service] is DOWN
📋 Cause: [crash reason from logs]
🔄 Action: Auto-restarted [service]
✅ Status: [service] is back online

📊 System Health:
• Memory: X GB / Y GB
• Disk: Z% used
• Services: N/N online