Dokploy is an open-source, self-hosted PaaS platform that brings Heroku-like deployments to your own VPS. It manages Docker deployments, Traefik routing, SSL certificates, and database provisioning — all through a clean web dashboard. Think of it as your own Render or Railway, running on infrastructure you control.
Because Dokploy orchestrates all your deployed applications, a Dokploy outage doesn't just take down one service — it can prevent new deployments, break SSL renewal, and make your entire fleet unmanageable. Monitoring Dokploy itself (not just the apps it hosts) is an important part of running a reliable self-hosted deployment platform.
In this tutorial you'll set up comprehensive uptime monitoring for Dokploy using Vigilmon — free tier, no credit card required.
Why monitoring Dokploy matters
Dokploy is a control plane for your self-hosted applications. When it's down:
- New deployments are blocked — you can't push code, trigger builds, or roll back a broken deployment
- SSL certificate management stops — Dokploy manages Traefik + Let's Encrypt; if Dokploy is unreachable, cert auto-renewal may break
- Deployment webhooks fail — Git provider webhooks (GitHub, GitLab, Gitea) can't trigger auto-deploy; your CI/CD pipeline silently stops working
- Database provisioning stops — any new Postgres, MySQL, MongoDB, or Redis instances can't be created
- Application visibility is lost — the dashboard that shows your running containers and logs becomes unavailable
Unlike a single application going down, a Dokploy outage puts your entire deployment workflow on hold. Detecting it quickly means you can restore it before engineers wonder why their pushes aren't deploying.
What you'll need
- A running Dokploy instance (self-hosted on a VPS or dedicated server)
- The Dokploy dashboard accessible on a domain or IP
- A free Vigilmon account — sign up takes 30 seconds
Understanding Dokploy's accessible endpoints
Dokploy is a Next.js application running behind Traefik. Its endpoints from a monitoring perspective:
| Endpoint | What it checks |
|----------|----------------|
| https://dokploy.example.com/ | Dashboard root — full stack health (Next.js, Traefik, reverse proxy) |
| https://dokploy.example.com/api/health | API health endpoint (available in recent versions) |
| https://dokploy.example.com/api/trpc/settings.isCloud | tRPC API liveness — verifies the API layer is responding |
| Port 3000 (TCP) | Dokploy's internal Next.js port (if exposed) |
The most reliable external check is the dashboard root — it exercises the full Traefik → Dokploy path. The API endpoints give you finer-grained signal.
Step 1: Verify Dokploy is reachable
Before adding monitors, confirm Dokploy responds correctly:
# Check the dashboard root
curl -s -o /dev/null -w "%{http_code}" https://dokploy.example.com/
# Should return 200 or 307 (redirect to login)
# Check the health API (if your version supports it)
curl -s https://dokploy.example.com/api/health | jq .
# Check Traefik is routing correctly
curl -sv https://dokploy.example.com/ 2>&1 | grep "< HTTP"
If you get a connection refused or 502, Traefik may be up but the Dokploy container is down. If you get no response at all, Traefik itself may be down.
Step 2: Monitor the Dokploy dashboard
The dashboard root is the primary health check — it confirms that Traefik is routing, the Dokploy container is running, and the Next.js app is serving responses.
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS as the type
- Set the URL to:
https://dokploy.example.com/ - Set check interval to 1 minute
- Under Expected response:
- Status code:
200(or307if your Dokploy redirects unauthenticated users to/login) - For redirect: accept both
200and307, or set the expected code to307if that's consistent
- Status code:
- Save the monitor
Note on redirects: Dokploy redirects unauthenticated requests to /auth/login. If your Vigilmon monitor follows redirects (the default), set expected status to 200 and response body contains Dokploy or Login. If you configure it to not follow redirects, expect 307.
Step 3: Monitor the login page directly
The login page (/auth/login) is always publicly accessible and returns a stable 200 regardless of authentication state — making it a more reliable monitor target than the root:
- Create a new HTTP / HTTPS monitor
- URL:
https://dokploy.example.com/auth/login - Expected status code:
200 - Response body contains:
Dokploy(or the page title string — check your version) - Check interval: 1 minute
- Save
Step 4: Monitor deployment webhook endpoints
Dokploy exposes webhook endpoints that Git providers (GitHub, GitLab, Gitea) call to trigger deployments. If these endpoints become unreachable, your auto-deploy pipeline silently breaks — pushes succeed in Git but nothing deploys.
Dokploy webhook URLs follow the pattern:
https://dokploy.example.com/api/deploy/{application-id}
To monitor a webhook endpoint:
- Create a new HTTP / HTTPS monitor
- URL:
https://dokploy.example.com/api/deploy/your-application-id - Method: GET
- Expected status code:
405(Method Not Allowed — GET isn't a valid webhook trigger, but the 405 confirms the endpoint is routed and listening) - Check interval: 5 minutes
- Save
This confirms that the deployment API path is reachable through Traefik and the application is handling requests — without actually triggering a deployment.
Step 5: Monitor application availability
Dokploy hosts your applications — but monitoring Dokploy doesn't tell you whether the apps it hosts are actually serving traffic. Add individual monitors for each application Dokploy manages:
For example, if Dokploy hosts your API at https://api.example.com:
- Create a new HTTP / HTTPS monitor
- URL:
https://api.example.com/health(or whatever health endpoint your app exposes) - Expected status code:
200 - Check interval: 1 minute
- Save
This separates two failure modes:
- Dokploy down — the platform itself is unreachable, your apps may still be running
- App down — Dokploy is fine but a specific application container has crashed or been misconfigured
Having monitors for both gives you precise diagnosis. If Dokploy is up and the app monitor is down, you need to restart the application. If both are down, you need to look at the VPS or Traefik layer.
Step 6: Monitor the Traefik TCP port
Traefik is Dokploy's reverse proxy and handles all inbound traffic. If Traefik crashes, every application hosted on Dokploy becomes unreachable simultaneously. Add a TCP monitor for Traefik's HTTPS port:
- Create a new TCP Port monitor
- Host:
dokploy.example.com - Port:
443 - Check interval: 1 minute
- Save
If the TCP monitor for port 443 fails while all HTTP monitors also fail, Traefik is the culprit. If HTTP monitors fail but port 443 TCP passes, Traefik is running but routing to a down backend.
Step 7: Monitor TLS certificate expiry
Dokploy manages Let's Encrypt certificates through Traefik. Vigilmon automatically monitors TLS cert expiry on any HTTPS monitor. To tune the threshold:
- Open your Dokploy dashboard monitor settings
- Under SSL certificate alerts, set warning to 14 days before expiry
Let's Encrypt certs expire every 90 days. Traefik auto-renews them, but if Traefik can't reach Let's Encrypt (firewall, rate limit, ACME challenge failure), the renewal silently fails. A 14-day warning gives you a comfortable window to intervene.
Step 8: Configure alert channels
- Go to Alert Channels → Add Channel → Email for on-call alerting
- Add your infrastructure team email
- For Slack/PagerDuty: Alert Channels → Add Channel → Webhook
- Assign all Dokploy monitors to your alert channels
Recommended alert priority tiers:
- Dashboard down → Critical alert (pager-worthy)
- Individual app down → High alert (Slack + email)
- TLS cert warning → Warning (Slack only, 14 days out)
Step 9: Diagnosing Dokploy alerts
When Vigilmon fires a Dokploy alert, triage in this order:
# 1. Check if the Dokploy Docker stack is running
docker ps --filter "name=dokploy"
# 2. Check Dokploy container logs
docker logs dokploy --tail 50
# 3. Check Traefik status
docker ps --filter "name=traefik"
docker logs traefik --tail 50
# 4. Check Traefik dashboard (if enabled, typically port 8080)
curl -s http://localhost:8080/api/overview | jq .
# 5. Restart Dokploy if the container is stopped
docker start dokploy
# 6. Check VPS disk space (full disk is a common cause of container crashes)
df -h
# 7. Check memory
free -m
Common Dokploy failure modes:
- Out of disk space — Docker images and build caches fill disks; VPS containers crash silently
- Traefik certificate store corrupted — delete and recreate the
acme.jsonfile and restart Traefik - Database connection failure — Dokploy uses PostgreSQL internally; check
docker logs dokploy-postgres
Recommended monitor set for Dokploy
| Monitor | Type | Alert Priority |
|---------|------|----------------|
| https://dokploy.example.com/auth/login | HTTP | Critical |
| https://dokploy.example.com/ | HTTP | High |
| https://dokploy.example.com/api/deploy/{app-id} | HTTP (expect 405) | High |
| dokploy.example.com:443 | TCP | Critical |
| TLS cert expiry | SSL | Warning (14 days) |
| Each hosted app's health endpoint | HTTP | High |
What's next
- Heartbeat monitoring — if you use Dokploy's scheduled tasks or run cron jobs in deployed containers, add Vigilmon heartbeat monitors to confirm those jobs are running on schedule
- Status page — create a public or internal status page that shows the health of your Dokploy platform alongside your hosted applications, giving your team a single place to check during incidents
- Database monitoring — Dokploy provisions databases for your apps; add monitors for each database TCP port to catch database failures independently of application failures
Get started free at vigilmon.online — no credit card, monitors running in under a minute.