Monitoring OliveTin with Vigilmon

OliveTin is an open-source web UI that lets non-technical users safely trigger predefined shell commands on a remote server without SSH access. Admins define allowed actions in a YAML config file; users click a button in the browser to run them. It's popular for routine sysadmin tasks — restarting services, clearing caches, running backups — handed off to team members who shouldn't have shell access. When you self-host it, uptime matters: a crashed Go process or a broken action means your team is blocked from running those tasks and is back to raising tickets. Vigilmon gives you HTTP uptime monitoring, API endpoint health checks, and alerting so OliveTin failures surface before your team notices.

What You'll Set Up

• HTTP uptime monitor for the OliveTin web interface (port 1337)
• API endpoint health checks (/api/Actions, /api/StartAction)
• Action execution latency monitoring
• Configuration validity probe (YAML config reload health)
• Action log and audit trail accessibility check
• Authentication middleware health check
• SSL/TLS certificate expiry alert

Prerequisites

• OliveTin running and reachable over HTTP/HTTPS (default port 1337)
• At least one action configured in config.yaml
• A free Vigilmon account

Step 1: Monitor the OliveTin Web Interface

The Go HTTP server is the single process that serves the UI, handles API calls, and executes shell commands. If it crashes or stops listening on port 1337, every action is blocked.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your OliveTin URL: https://olivetin.yourdomain.com (or http://your-server-ip:1337 for a direct install).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

OliveTin serves a single-page application at the root path. A 200 response confirms the Go process is running and the static UI assets are being served.

Step 2: Monitor the Actions API Endpoint

OliveTin exposes a REST API at /api/Actions that returns the list of configured actions. This endpoint is hit by the UI on every page load. If it returns an error, the button grid is empty and users cannot trigger anything.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://olivetin.yourdomain.com/api/Actions.
3. Set Expected HTTP status to 200.
4. Set Expected body contains to actions — the response JSON always includes this key when at least one action is configured.
5. Check interval: 2 minutes.
6. Click Save.

A 200 response with actions in the body confirms that the config was loaded correctly and OliveTin can serve its action list.

Step 3: Monitor the StartAction API Endpoint

The /api/StartAction endpoint is what actually executes shell commands. Probe it to confirm the action execution pipeline is healthy:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://olivetin.yourdomain.com/api/StartAction.
3. Set Method to POST.
4. Set Expected HTTP status to 200 or 400 — a 400 (bad request, because the monitor sends no body) still confirms the endpoint is alive and routing; a 502 or 504 means the backend has crashed.
5. Check interval: 5 minutes.
6. Click Save.

This is a lightweight liveness probe — you are not executing a real action, just confirming the route handler is registered and the process is running.

Step 4: Monitor Action Execution Latency

OliveTin actions have variable execution times depending on the shell command. Tracking response time on a lightweight canary action reveals when the process execution environment is under load — slow system calls, a hung subprocess, or resource exhaustion before the action itself errors out.

Set up a canary action in your config.yaml that runs a trivially fast command:

actions:
  - title: Health Check
    shell: echo ok
    icon: ❤️

After reloading OliveTin's config, add a Vigilmon monitor that fires this action via the API:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://olivetin.yourdomain.com/api/StartAction.
3. Method: POST, body: {"actionTitle":"Health Check"}.
4. Expected HTTP status: 200.
5. Expected body contains: ok.
6. Check interval: 5 minutes.
7. Click Save.

Set a Response time alert threshold of 2 000 ms — a simple echo ok should complete in under 100 ms, so anything over 2 seconds indicates the execution environment is degraded.

Step 5: Configuration Validity Check

OliveTin reads config.yaml at startup and on reload. A YAML syntax error or a missing required field prevents OliveTin from starting or serving updated actions. Detect configuration drift by checking whether the actions API still returns the expected set of actions after a config change:

1. After any config.yaml edit, verify OliveTin reloaded successfully by checking the /api/Actions monitor from Step 2.
2. Add Expected body contains to include the title of a specific critical action: e.g. Restart Nginx.
3. If that string disappears from the response, the config reload failed or the action was accidentally removed.

This turns your existing monitor into a config validity probe — no additional setup required.

Step 6: Action Log and Audit Trail Accessibility

OliveTin keeps an audit log of every action execution. If the log endpoint becomes inaccessible, operators lose visibility into what commands were run and by whom. Probe the logs page or API:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://olivetin.yourdomain.com/api/ExecutionTrack (or the equivalent endpoint in your OliveTin version — check the UI's network tab).
3. Expected HTTP status: 200.
4. Check interval: 10 minutes.
5. Click Save.

This also validates that OliveTin's internal execution tracking database (SQLite by default) is accessible.

Step 7: Authentication Middleware Health

If you have configured OliveTin with basic auth or proxy-based authentication (e.g. behind Authelia or Authentik), a misconfigured auth middleware can lock out all users while the OliveTin process itself is healthy.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://olivetin.yourdomain.com.
3. Expected HTTP status: set to 401 if you expect unauthenticated requests to be rejected, or 200 if the monitor's IP is in an allowlist.
4. Do not add credentials to the monitor — you want to detect auth bypass (unexpected 200) as well as a broken auth layer (unexpected 500).
5. Check interval: 5 minutes.
6. Click Save.

If basic auth is enabled and this monitor returns 200, your auth layer has silently broken — all endpoints are publicly accessible.

Step 8: SSL/TLS Certificate Expiry

OliveTin is often accessed from internal tools, CI pipelines, and scripts that call the API programmatically. A lapsed certificate breaks all of these callers at once.

1. Open the HTTP monitor created in Step 1.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

Step 9: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
2. Set Consecutive failures before alert to 2 on the web interface monitor — transient network blips are common; two consecutive failures are actionable.
3. Route the /api/StartAction and action execution latency alerts to a higher-urgency channel — a broken action execution pipeline blocks your team from running any automation.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP — web interface | https://olivetin.yourdomain.com | Go process crash, port 1337 not listening | | HTTP — Actions API | /api/Actions | Config load failure, routing broken | | HTTP — StartAction API | POST /api/StartAction | Action execution pipeline down | | HTTP — canary action | POST /api/StartAction (echo ok) | Slow execution environment, process hang | | HTTP — audit log | /api/ExecutionTrack | Log DB inaccessible, tracking broken | | HTTP — auth check | / (unauthenticated) | Auth middleware bypass or failure | | SSL certificate | OliveTin domain | TLS renewal failure |

Self-hosting OliveTin means your team's ability to run routine admin tasks depends entirely on a single Go process and its YAML config. With Vigilmon watching the API layer and execution pipeline, you catch a crashed process before anyone raises a ticket, a config reload failure before missing actions confuse users, and a broken auth layer before your command executor is accidentally exposed to the network.