Logs & monitoring

Tail and search logs across every service, set log levels, and publish a public status page.

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)

# Replay history, then keep tailing
spky logs --since 2h
spky logs --since 2026-05-20T09:00:00Z

# Bounded window: one-shot, closes when exhausted
spky logs --since 3d --until 2d

# Server-side regex on the message
spky logs --grep 'panicked|timed out'

# Interactive TUI browser, opening in follow mode
spky logs -i
spky logs -i -F

Flag	What it does
`--filter <services>`	One or more of `surrealdb`, `scheduler`, `ssp`, `backend`, `frontend`, comma-separated. `spooky` is shorthand for `ssp` plus `scheduler`.
`--split h\|v`	Show each service in its own pane, stacked or side by side.
`--since <when>`	Replay history from a duration (`2h`, `3d`, `1h30m`) or an RFC-3339 timestamp, then keep tailing.
`--until <when>`	Bound the window. Turns the command into a one-shot that closes when the window is exhausted.
`--grep <regex>`	Server-side match on the log message, for both history and live tail.
`-i`, `--interactive`	Open a TUI browser with scroll, search, and service and time filters, instead of streaming to stdout.
`-F`, `--follow`	TUI only. Start in follow mode. Without it the TUI opens paused at the newest entry; press `f` to go live.

From the dashboard

The scheduler’s admin dashboard has a live log view over the same scheduler and SSP sources, with the SSP picked per instance. It is the quicker route when you are already looking at a cluster’s health, and it works against a self-hosted scheduler, where spky logs has no cloud deployment to talk to.

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.

Note

Trace mode is chatty: a multi-million-row bootstrap produces a line per record. Switch back to info with another spky deploy once you have what you need.

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:

Status	Color	Meaning
live	Green	Deployment is running
building	Yellow	Deployment in progress (pending, provisioning, migrating, or deploying)
error	Red	Deployment failed
unknown	Gray	No deployment found

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.

Staging

For staging deployments, use the staging API URL: https://api-stg.sp00ky.cloud/v1/badge/your-project-slug

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:

Result	Counts as	Conditions
up	success	HTTP `2xx` or `3xx`
down	failure	`4xx`, `5xx`, timeout, connection refused, or TLS/DNS error

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 }
      ]
    }
  ]
}