Logs & Monitoring

Viewing Logs

Tail logs from your cloud deployment in real time:

# All services
spky logs

# Filter by service
spky logs --filter surrealdb
spky logs --filter ssp
spky logs --filter backend
spky logs --filter frontend

# Multiple services (comma-separated)
spky logs --filter ssp,surrealdb

# Blueprint shorthand: "spooky" = ssp + scheduler
spky logs --filter spooky

# Split view
spky logs --filter ssp,surrealdb --split h   # horizontal (stacked)
spky logs --filter ssp,surrealdb --split v   # vertical (side-by-side)

Setting Log Level

logLevel in sp00ky.yml sets RUST_LOG on the Scheduler and SSP containers in both spky dev and spky deploy. Default is info.

# Bump every container to trace level
logLevel: trace

# Or split per environment
logLevel:
  dev: trace
  cloud: info

The value is a tracing-subscriber directive, so target-specific overrides work too:

# RUST_LOG directives also work
logLevel: info,ssp=debug,scheduler=trace

What trace adds

At trace, the Scheduler emits one line per replica query (proxy passthroughs, WAL applies, ad-hoc) and one line per record during the upstream-clone bootstrap (table=… id=… fields=N). The Scheduler also logs the resolved namespace + database it bootstraps from at info, so even default-level logs make the target explicit.

Use it to diagnose:

• “I deployed but my data isn’t showing up” — confirm the Scheduler is bootstrapping from the namespace/database you expect.
• “This live query never updates” — every query the Scheduler runs is in the trace log, so you can see what fired and what didn’t.
• Bootstrap performance regressions — per-table fetch_ms / insert_ms are logged at info; per-record sequence is at trace.

Status Badge

Add a live deployment status badge to your GitHub README or any webpage. The badge is a public SVG endpoint — no authentication required.

![Sp00ky Status](https://api.sp00ky.cloud/v1/badge/your-project-slug)

Or in HTML:

<img src="https://api.sp00ky.cloud/v1/badge/your-project-slug" alt="Sp00ky Status" />

The badge displays the current deployment status:

The badge is never cached — it always reflects the current state. You can also append .svg to the URL: /v1/badge/your-project-slug.svg.

Uptime Status Page

Every running deployment is health-checked automatically — there is nothing to enable. The results are published as a public, unauthenticated status page, reached by your project slug:

https://api.sp00ky.cloud/v1/uptime/your-project-slug

The page shows a 30-day uptime heatmap — one bar per UTC day — for each monitored endpoint, plus the overall percentage across them. An unknown slug, or a project with no checks yet, renders a graceful “No uptime data yet” rather than an error.

How checks work

Sp00ky probes each running deployment’s public endpoints (such as your web frontend and backend) once per minute, with a 30-second timeout:

A day’s percentage is up / total checks for that UTC day; days with no checks render as gaps rather than 0%. Responses are cached for 60 seconds.

JSON

Append .json to get the same data as a machine-readable payload — useful for a custom dashboard or an external monitor:

https://api.sp00ky.cloud/v1/uptime/your-project-slug.json

{
  "slug": "your-project-slug",
  "uptime_pct": 99.97,
  "has_data": true,
  "window_days": 30,
  "endpoints": [
    {
      "name": "web",
      "uptime_pct": 99.98,
      "days": [
        { "date": "2026-05-20", "total": 1440, "up": 1440, "has_data": true, "pct": 100 },
        { "date": "2026-05-21", "total": 1440, "up": 1437, "has_data": true, "pct": 99.79 }
      ]
    }
  ]
}