Monitoring Budibase with Vigilmon: Health Endpoint, Web Builder, REST API & SSL Alerts

Budibase is a self-hosted open-source low-code platform for building internal tools — admin panels, approval workflows, CRUD interfaces, and customer portals — that runs entirely on your own infrastructure. Engineering teams rely on Budibase to give operations and support teams controlled access to internal data without writing bespoke frontends. When Budibase goes down, every internal tool built on the platform becomes inaccessible: customer support loses their admin panels, operations loses their dashboards, and any automation pipelines that call the Budibase REST API stop. Budibase also exposes a built-in REST API proxy that forwards external API calls through the platform — when the proxy service fails, every app widget that reads external data goes blank. Vigilmon gives you external visibility into Budibase's health endpoint, web builder, REST API, proxy TCP port, and SSL certificate so failures are caught within 60 seconds.

What You'll Build

• A monitor on Budibase's /health health endpoint
• An HTTP monitor for the Budibase web builder UI
• An HTTP monitor for the REST API liveness check (/api/applications returning 401 confirms the API is alive)
• A TCP monitor for the Budibase proxy service port
• SSL certificate monitoring for your Budibase domain
• An alerting setup that separates application failures from proxy service degradation

Prerequisites

• A running Budibase instance with a public or network-reachable domain
• HTTPS configured (e.g., https://budibase.example.com)
• A free account at vigilmon.online

Step 1: Verify Budibase's Health Endpoint

Budibase exposes a health check at /health that confirms the application server and its backing services are responding:

curl -i https://budibase.example.com/health

A healthy instance returns HTTP 200:

HTTP/2 200
content-type: application/json

{"status":"RUNNING"}

This endpoint requires no authentication and is designed for uptime probes. A 200 with a running status confirms the Node.js app server is up and CouchDB (Budibase's primary database) is reachable. A non-200 response or a timeout indicates the application server has crashed, CouchDB is unreachable, or a container restart is in progress.

Step 2: Create a Vigilmon HTTP Monitor for the Health Endpoint

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://budibase.example.com/health.
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: RUNNING.
7. Label: Budibase Health.
8. Click Save.

This monitor catches:

• Budibase Node.js server crashes or OOM kills
• CouchDB connectivity failures — Budibase stores all app definitions, data models, automation rules, and user records in CouchDB; if CouchDB goes down, no apps load and no data is queryable
• Worker process failures that prevent automation execution
• Redis session failures that log out authenticated users

The RUNNING keyword check ensures the server is reporting a healthy status — not just a 200 from a reverse proxy fronting a failed backend.

CouchDB dependency: Every Budibase application, table schema, automation, user role, and row of app data is stored in CouchDB. A CouchDB failure makes Budibase entirely non-functional — all apps return errors, no data is readable or writable, and the builder itself cannot open any application. The /health endpoint is your first line of defence against database-layer failures.

Step 3: Monitor the Budibase Web Builder

The Budibase web builder is a Vue.js single-page application that developers and no-code users rely on to build and modify internal tools. Monitor it independently from the API to catch reverse proxy failures and static asset serving problems:

1. Add Monitor → HTTP.
2. URL: https://budibase.example.com.
3. Check interval: 60 seconds.
4. Expected status: 200.
5. Keyword: Budibase.
6. Label: Budibase Web Builder.
7. Click Save.

This monitor catches nginx or reverse proxy failures, CDN misconfiguration, and static file serving errors that prevent developers from opening the builder — even when the backend API is healthy. A broken builder means no app changes, no table edits, no automation modifications, and no user management until the front-end serving is restored.

Step 4: Monitor the REST API Liveness

Budibase exposes a full REST API that external systems can use to trigger automations, read and write app data, and manage resources programmatically. Calling /api/applications without authentication returns 401 Unauthorized — which is the correct response confirming the API is alive and processing requests:

curl -i https://budibase.example.com/api/applications
# Expected: HTTP 401 (API is alive, authentication is enforced)

1. Add Monitor → HTTP.
2. URL: https://budibase.example.com/api/applications.
3. Check interval: 60 seconds.
4. Expected status: 401.
5. Label: Budibase REST API.
6. Click Save.

A 401 is the correct liveness signal: it proves the API server accepted the connection, parsed the request, and returned a proper HTTP response. A 502 or 504 means the proxy is running but the Budibase Node.js process is not responding. A timeout means the application or network layer has failed entirely.

Step 5: Create a TCP Monitor for the Proxy Service Port

Budibase includes a built-in proxy service that forwards REST API calls and datasource connections from app widgets to external APIs and databases. The proxy runs as a separate worker on port 4002 in the default Budibase Docker deployment. When it crashes, every app widget that reads from an external datasource returns an error, even if the main app server and CouchDB are healthy.

1. Add Monitor → TCP.
2. Host: budibase.example.com.
3. Port: 4002.
4. Check interval: 60 seconds.
5. Response timeout: 10 seconds.
6. Label: Budibase Proxy TCP.
7. Click Save.

Note: In Budibase's default Docker Compose deployment, the proxy port may be behind the main nginx reverse proxy and not directly externally accessible. If direct TCP access is unavailable, skip this monitor and rely on the REST API monitor — proxy failures that degrade datasource connections will eventually surface as API-level errors or app data loading failures that your users report. If you can expose the port to your monitoring network, the TCP check provides earlier failure detection.

Step 6: Monitor SSL Certificates

Budibase hosts internal tools your team uses every day. An expired SSL certificate:

• Locks all users out of every app on the platform simultaneously
• Breaks any external systems that call the Budibase REST API over HTTPS
• Prevents new apps from being built or existing apps from being modified
• May cause the Budibase proxy to fail when it validates TLS for outbound datasource calls

1. Add Monitor → SSL Certificate.
2. Domain: budibase.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | /health | Non-200 or RUNNING missing | Check Budibase container; inspect CouchDB and Redis connectivity; review app server logs | | Web Builder | Non-200 or keyword missing | Check nginx/reverse proxy; verify static assets served; inspect container logs | | REST API | Non-401 response | Check Node.js app server; inspect API router; verify worker processes are running | | Proxy TCP Port | Connection refused or timeout | Restart Budibase proxy worker; check port 4002; inspect proxy service logs | | SSL certificate | < 30 days to expiry | Renew certificate; verify Let's Encrypt auto-renewal is functioning |

Alert after: 2 consecutive failures for HTTP monitors. 1 failure for the TCP monitor — a crashed proxy process will not self-recover.

Common Budibase Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Node.js app server crash | Health endpoint unreachable; alert within 60 s | | CouchDB down or disk full | Health check fails; all apps and data inaccessible | | Redis session store failure | Users logged out; authentication fails across all apps | | Proxy service crash | Proxy TCP monitor fires; all datasource widgets show errors | | Worker process OOM-killed | Automations stop executing; app triggers fail silently | | Reverse proxy misconfiguration | Web builder monitor fires; backend may still be healthy | | Static asset serving failure after upgrade | Builder keyword check fails; blank screen on load | | SSL certificate expires | SSL monitor alerts at 30 days; all platform access blocked | | DNS misconfiguration | All monitors fire simultaneously | | Container restart loop | Health endpoint intermittently returns 503; flapping alerts |

Internal tools are the operational backbone of your support and ops teams — when Budibase goes down, they lose access to every admin panel and dashboard built on the platform simultaneously. Vigilmon watches Budibase's health endpoint, web builder, REST API, proxy service, and SSL certificate so you're alerted within 60 seconds of any failure, before your team files a help ticket wondering why their tools are blank.

Start monitoring Budibase in under 5 minutes — register free at vigilmon.online.