Logs & Monitoring
Viewing Logs
Tail logs from your cloud deployment in real time:
Setting Log Level
logLevel in sp00ky.yml sets RUST_LOG on the Scheduler and SSP containers in both spky dev and spky cloud deploy. Default is info.
The value is a tracing-subscriber directive, so target-specific overrides work too:
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_msare logged atinfo; per-record sequence is attrace.
Trace mode is chatty — a multi-million-row bootstrap produces a line per record. Switch back to info with another spky cloud 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.
Or in HTML:
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.
For staging deployments, use the staging API URL: https://api-stg.sp00ky.cloud/v1/badge/your-project-slug