---
title: "Uptime Kuma — No REST API; Socket.IO and SQLite Management"
aliases: [uptime-kuma-api, uptime-kuma-management, uptime-kuma-sqlite, uptime-kuma-socketio]
tags: [uptime-kuma, monitoring, sqlite, socketio, homelab, selfhosted]
sources:
  - "daily/2026-04-21.md"
created: 2026-04-21
updated: 2026-04-21
---

# Uptime Kuma — No REST API; Socket.IO and SQLite Management

Uptime Kuma does not expose a traditional REST API for programmatic management. All UI interactions use Socket.IO (WebSocket). For automated or scripted operations — like deleting monitors in bulk — the most practical approach is direct SQLite access to the database file at `/opt/uptime-kuma/data/kuma.db`.

## Key Points

- **No REST API** — Uptime Kuma uses Socket.IO exclusively; there are no `GET /monitors` or `DELETE /monitors/123` endpoints
- **SQLite database** at `/opt/uptime-kuma/data/kuma.db` is the authoritative data store; safe to query and modify when Kuma is stopped
- **Delete monitors via SQL:** `DELETE FROM monitor WHERE id IN (6, 10)` — simpler than scripting Socket.IO
- **Monitor IDs are visible in the browser** — open Uptime Kuma UI, click a monitor, the ID appears in the URL `/#/details/6`
- The unofficial community API (`louislam/uptime-kuma-api` npm package) wraps Socket.IO and is the safest programmatic interface

## Details

### Why There Is No REST API

Uptime Kuma's architecture was originally designed as a real-time dashboard — all state changes propagate via WebSocket events to connected clients. The author chose Socket.IO as the sole communication layer. This works well for the UI but makes scripted management non-standard.

The official project position (as of 2026-04): REST API is a feature request, not planned for the near term. Use the Socket.IO interface or direct SQLite access.

### Finding Monitor IDs

**Via the UI:**
1. Open Uptime Kuma at `http://<host>:3001`
2. Click a monitor
3. URL changes to `http://<host>:3001/#/details/6` — the ID is `6`

**Via SQLite:**
```bash
sqlite3 /opt/uptime-kuma/data/kuma.db \
  "SELECT id, name, url FROM monitor ORDER BY id;"
```

### Deleting Monitors via SQLite

When running Uptime Kuma in a Proxmox LXC container:

```bash
# Access the container and delete monitors
ssh pve "pct exec 110 -- sqlite3 /opt/uptime-kuma/data/kuma.db \
  'DELETE FROM monitor WHERE id IN (6, 10)'"
```

Or if logged into the LXC directly:
```bash
sqlite3 /opt/uptime-kuma/data/kuma.db \
  "DELETE FROM monitor WHERE id IN (6, 10);"
```

Uptime Kuma can remain running during read queries but **stop it before writes** to avoid database corruption:

```bash
# Safer approach for modifications
systemctl stop uptime-kuma
sqlite3 /opt/uptime-kuma/data/kuma.db "DELETE FROM monitor WHERE id IN (6, 10);"
systemctl start uptime-kuma
```

### Community Socket.IO API (Programmatic Use)

For more complex automation, the `louislam/uptime-kuma-api` npm package (unofficial) wraps the Socket.IO interface:

```js
const { UptimeKumaApi } = require('uptime-kuma-api');

const api = new UptimeKumaApi({ baseURL: 'http://192.168.1.x:3001' });
await api.loginByPassword({ username: 'admin', password: '...' });
await api.deleteMonitor(6);
await api.disconnect();
```

This is more reliable than raw Socket.IO scripting and survives minor Kuma version updates.

### Key Database Tables

```sql
-- Main monitor config
SELECT id, name, type, url, active FROM monitor;

-- Notification channels
SELECT id, name, type FROM notification;

-- Monitor-to-notification mapping
SELECT monitor_id, notification_id FROM monitor_notification;

-- Heartbeat history (can grow large)
SELECT monitor_id, status, time FROM heartbeat ORDER BY time DESC LIMIT 20;
```

### Connecting Uptime Kuma Alerts to Webhook

To send alerts to a monitoring agent webhook (e.g., at `http://192.168.1.225:9111/alert/uptime-kuma`):

1. **Settings → Notifications → Add Notification**
2. Type: `Webhook`
3. URL: `http://192.168.1.225:9111/alert/uptime-kuma`
4. Save
5. For each monitor: open monitor → Edit → Notifications → enable the webhook

This must be done via the UI — there is no bulk "assign notification to all monitors" operation.

## Related Concepts

- [[wiki/concepts/beszel-monitoring-deployment]] — Beszel as a complementary monitoring tool (server metrics vs uptime monitoring)
- [[wiki/concepts/homarr-proxmox-integration]] — Homarr integrates with Uptime Kuma to display monitor status in the dashboard
- [[wiki/homelab/_index]] — full homelab monitoring stack context

## Sources

- [[daily/2026-04-21.md]] — ERPNext (monitor ID 6) and Monica (ID 10) decommissioned; deletion via SQLite recommended as `pct exec 110 -- sqlite3 ... 'DELETE FROM monitor WHERE id IN (6, 10)'`; Uptime Kuma uses Socket.IO not REST API confirmed
