SolStatus: Uptime Monitoring That Runs on Cloudflare Workers

What it monitors, and what it tells you

SolStatus is an uptime monitoring service that is easy and cheap to run at scale. You create endpoint checks and it measures three things: whether the endpoint is up, what the latency was, and what status code came back. The package description is more specific about the deployment target, since it says to self host a low-cost, globally-distributed uptime monitoring service on Cloudflare. The demo dashboard in the documentation shows the shape of the output. The alerting story is deliberately narrow and worth reading closely: it supports OpsGenie, and alerts fire when there are two or more consecutive failures. That is a design decision rather than an omission, since alerting on a single failed probe produces noise, and a rule of two failures filters out the transient blips that make people disable monitors.

Installing it and running the CLI

The quick start is two commands.

# Install dependencies
nub install

# Run the CLI
nub run cli --help

The repository requires Node.js 24.15.0 and Nub 0.9.6, and those are exact versions rather than ranges, which is a reasonable choice for a tool that provisions infrastructure. The CLI is the interface to everything else, and its own help is the reference for what it can do.

# Deploy infrastructure
nub run cli -- --fqdn uptime.example.com

The fully qualified domain name is the argument that identifies your deployment, and the same flag with a stage produces a production deployment, while a phase of destroy tears the infrastructure down again.

# Deploy to production
nub run cli -- --fqdn uptime.example.com --stage prod

The two deployment paths, Cloudflare and Alchemy

The deployment section is where the architecture becomes visible. Production workers and the dashboard deploy through Alchemy, not Wrangler, and the CLI is what ties them together, with the fully qualified domain name and the prod stage passed on the command line. Wrangler stays in the picture for local D1 and for the local API workers, and those commands share D1 state under a directory in the infra package, which is the detail that makes local development coherent rather than a separate database. The reason for the split is visible in the project structure. The database is D1, a Cloudflare product, so local development of the data layer runs against local D1 through Wrangler, while the deployed workers and the web app run on Alchemy. The environment example shows the account credentials the CLI needs, with a Cloudflare account id and API token, and the note that they can also be provided as a CLI flag.

Running it locally, and the worker split

For local work the recommendation is to run dev from the root of the repository, and the first step is to copy a dev vars example file into place in the infra package. Then you confirm you are pointed at the right Cloudflare account with wrangler whoami, and set up the database.

# this is a convenience script that runs db:touch, db:generate, db:migrate, and db:seed
nub run db:setup

The repository uses multiple workers split into their own workspaces, and the dev script starts the API and the TanStack Start app together. You can also run the pieces separately, and the API itself splits further into an executor worker and a trigger worker.

# Run the API executor worker
nub run --filter '@solstatus/api' dev:api-exec

That executor and trigger split is the design decision that makes the service scale, since the two roles have very different workloads. The trigger side schedules and dispatches checks, and the executor side performs them, so a burst of endpoints does not have to share a process with the thing deciding what to check.

The package layout and the tooling around it

The root package manifest describes a monorepo with a workspaces array over packages/*, and the published packages are the same five the CI section names. solstatus is the main CLI package, @solstatus/common holds shared utilities and schemas, @solstatus/api holds the API workers, @solstatus/app is the web application, and @solstatus/infra holds the infrastructure tools. The root also carries the bin entry pointing at the CLI source, the typecheck script that runs the compiler once per package, oxlint and oxfmt for linting and formatting, and vitest for the tests. The repository has a VERSION file, a nub.lock, a skills-lock.json, a .devcontainer directory, and agent-oriented directories at .agents/ and .cursor/, plus a .tegami/ directory, which is the tool the release section names as the component that versions and publishes the npm packages.

The release process, and the secrets the CLI needs

Releases are handled by a tool called Tegami, which versions and publishes the npm packages after a Validate job succeeds on master. The setup steps for enabling that are documented in the readme: create an npm access token, add it as a GitHub secret named NPM_TOKEN, enable the option allowing GitHub Actions to create and approve pull requests, and create a release:none label for toolchain-only pull requests. The last of those is a neat touch, since it lets a dependency bump skip the release pipeline entirely. The environment example shows the other secrets the system needs, with an optional Alchemy passphrase the CLI will autogenerate as a random 32 character hexadecimal string, and a better-auth secret. The licence is AGPL-3.0-only, and the last push was on 2026-10-20.

Dependency management, and where the limits are

Dependabot handles the dependency graph, creating pull requests weekly for npm dependencies grouped as minor and patch updates, and monthly for GitHub Actions, with pull request limits set so the queue does not overwhelm the maintainers. There is a manual path too, using ncu with a minor target followed by an install.

nub exec ncu -t minor -u
nub install

The honest limit of this project is the scope of what it monitors. The description says to create endpoint checks for uptime, latency and status code, and that is the whole feature list, so if you need certificate expiry checks, DNS checks, multi-region probes from your own network, or synthetic transactions, this is not the tool. What it does instead is make the common case nearly free to run, with a single command to provision infrastructure that is globally distributed, which is the part a small team actually struggles to justify to itself.

Editorial conclusion

SolStatus fits a small team or an individual who wants uptime and latency monitoring on infrastructure they already pay for, and who is comfortable with Cloudflare accounts and a command line deployment. It is the wrong choice if you need a broad set of check types, since the documented scope is endpoint checks for uptime, latency and status code, and the wrong choice if you need a mature alerting integration, since OpsGenie is the one named. Before you deploy, run the CLI against a staging stage first and confirm your alert policy fires only after the second consecutive failure.

Frequently asked questions

Official sources

1. Issues
2. jonbeckman/solstatus on GitHub
3. License: AGPL-3.0
4. README
5. Releases