Monitoring Turso (libSQL) with Vigilmon: HTTP API Health, Replication & Edge Replica Uptime

Turso is a distributed database built on libSQL (a fork of SQLite) that replicates data to edge locations around the world. It exposes a simple HTTP API that makes database health checks straightforward — but with replication across dozens of edge regions, there are more things to monitor than a single-server database. Vigilmon lets you probe Turso's HTTP API and edge replicas from outside your application, alerting you the moment connectivity or replication health degrades.

What You'll Build

An HTTP monitor on Turso's database HTTP API endpoint
A keyword assertion to confirm successful query execution
Edge replica health checks for latency-sensitive applications
Alerting tuned for Turso's distributed topology

Prerequisites

A Turso account with at least one database (from turso.tech)
A Turso auth token for your database
A free account at vigilmon.online

Step 1: Locate Your Turso Database URL

Every Turso database has an HTTPS endpoint. Find it in the Turso dashboard or via the CLI:

turso db show YOUR_DATABASE_NAME

The URL looks like:

https://your-database-name-yourorg.turso.io

Turso also provides the libsql:// protocol for native libSQL clients, but for Vigilmon's HTTP monitors, you'll use the HTTPS URL.

Step 2: Create an HTTP Monitor on the Turso HTTP API

Turso's HTTP API accepts SQL queries over HTTPS. You can use it directly for health checks.

Create a monitor that executes a lightweight query:

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://your-database-name-yourorg.turso.io/v2/pipeline
Method: POST
Request headers:
- Authorization: Bearer YOUR_TURSO_AUTH_TOKEN
- Content-Type: application/json

Request body:

{"requests": [{"type": "execute", "stmt": {"sql": "SELECT 1"}}, {"type": "close"}]}

Expected status: 200
Keyword: "results" (present in every successful Turso pipeline response)
Interval: 60 seconds
Click Save.

This validates the full path: Turso's edge routing → your specific database → query execution → response.

Step 3: Add a Query-Level Keyword Assertion

The /v2/pipeline response includes query results or error details. Strengthen your assertion by checking for success markers:

{
  "results": [
    {"type": "ok", "response": {"type": "execute", "result": {...}}},
    {"type": "ok", "response": {"type": "close"}}
  ]
}

Update your monitor's keyword to "type": "ok" — this confirms not just that Turso responded, but that the query succeeded. If the database is in an error state, the response will contain "type": "error" instead, and the keyword check will fail.

Step 4: Monitor Edge Replica Locations

If your application uses Turso's edge replicas for low-latency reads in specific regions, create separate monitors targeting those regions. Turso routes requests to the nearest replica by default, but you can force a specific location:

Check your replica list:

turso db locations YOUR_DATABASE_NAME

For each critical region, create a Vigilmon monitor with location-specific context:

Add Monitor → HTTP for each replica region.
Use the same /v2/pipeline endpoint and SELECT 1 body.
Label each monitor with the region (e.g., "Turso — EU West", "Turso — US East").
Set a tighter response timeout: 3 seconds (edge replicas should respond in < 100 ms; 3 s means something is wrong).

When a regional replica degrades, you'll know which location is affected — helping you decide whether to implement fallback routing.

Step 5: Monitor Replication Lag with an Application Health Endpoint

Turso replicates writes from the primary to edge replicas asynchronously. To detect replication lag, expose a health endpoint in your application that writes a timestamp, reads it back from an edge replica, and computes the lag:

// Example health endpoint
app.get('/health/db', async (req, res) => {
  try {
    const ts = Date.now();
    await primaryClient.execute(`INSERT OR REPLACE INTO _health (id, ts) VALUES (1, ${ts})`);
    const result = await edgeClient.execute('SELECT ts FROM _health WHERE id = 1');
    const lag = ts - Number(result.rows[0][0]);
    
    if (lag > 5000) {
      return res.status(503).json({ status: 'degraded', lag_ms: lag });
    }
    res.json({ status: 'ok', lag_ms: lag });
  } catch (err) {
    res.status(503).json({ status: 'error', message: err.message });
  }
});

Configure Vigilmon to monitor this endpoint:

URL: https://your-app.example.com/health/db
Expected status: 200
Keyword: "status": "ok"

Step 6: Monitor Turso's Service Status

Turso publishes infrastructure status at https://status.turso.io/. Add a Vigilmon monitor to detect platform-level incidents:

Add Monitor → HTTP.
URL: https://status.turso.io/
Keyword: All Systems Operational
Interval: 5 minutes

This gives you immediate context when your own database monitors start failing — distinguishing between a Turso platform incident and a problem in your own configuration.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, set up your alert channels:

| Monitor | Trigger | Notes | |---|---|---| | Turso HTTP API | Non-200 or keyword missing | Check Turso dashboard for database state | | Edge replica response time | Timeout > 3 s | Replica degraded; check status.turso.io | | App health endpoint | "status": "ok" missing | Replication lag detected; check write patterns | | Turso status page | All Systems Operational missing | Platform-level incident; wait for resolution |

Alert after: 1 consecutive failure for API monitors. 2 consecutive failures for replica monitors (brief routing blips are normal).

Re-notify: every 5 minutes while the primary API monitor is down.

What Vigilmon Catches in a Turso Deployment

| Scenario | Server logs | Vigilmon | |---|---|---| | Turso database suspended or deleted | 404 from API | HTTP monitor fires within 60 s | | Edge replica offline in a region | Regional latency spike | Regional monitor times out | | Auth token expired or revoked | 401 from API | HTTP monitor fires (non-200) | | Replication lag exceeds threshold | Not visible in app logs | App health endpoint monitor fires | | Turso platform incident | Not in your logs | Status page keyword monitor fires |

Turso's edge distribution makes SQLite available globally, but distributing data across regions means more things can fail independently. Vigilmon monitors each layer — the primary HTTP API, regional edge replicas, and platform status — giving you visibility into which part of the system is misbehaving before your users notice the latency spike or connection failure.

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