A $5-a-month monitoring SaaS on Workers, Turso and R2 is a cost datapoint, not a blueprint

A solo founder has published the architecture of Pulse, a server monitoring product aimed at Latin American small businesses, which runs entirely on Cloudflare Workers, Turso (libsql) and R2 with a Go agent that installs on Linux, macOS, Windows or Docker from one curl command ^[1][2]. The author says the platform costs about $5 a month to operate for its first hundred customers and hits sub-second alert latency at the edge ^[3][4].

Treat the $5 as a floor measurement rather than a recommendation. Spread across a full hundred customers it works out to roughly five cents each per month ^[16], which is the number worth writing down: it is what a multi-tenant SaaS costs to keep alive before it has any scale problems. The post gives the figure as a single number and does not break it down by service ^[19], so it is an operator's claim about their own bill, not an itemised invoice.

The shape underneath it is unusually flat. One Worker, pulse-api, serves five kinds of traffic: public HTML, the authenticated /app/* dashboard, the agent API at /agent/register and /ingest, a Telegram webhook handling two-way commands such as /silence and /status, and a Stripe webhook ^[6]. A scheduled handler fires every minute on a `* * * * *` cron ^[7], evaluating thresholds, running HTTP uptime checks, and once an hour at minute 5 running retention cleanup ^[8]. There is no separate cron worker, no queue, no background service ^[9]. The wrangler config is correspondingly small: one custom domain route, a Turso URL, one R2 bucket for release binaries, one AI binding ^[10]. Alongside those sit Workers AI (Llama 3.3) for alert interpretation, Resend for magic-link email, the Telegram Bot API and Stripe ^[5].

That flatness is where the latency claim needs reading carefully. The author's stated constraint was under one second from threshold breach to notification ^[13], and the chosen design explicitly rejects inline streaming evaluation in favour of a plain 60-second cron that reads enabled thresholds and joins them against recent samples ^[11]. Both things can be true, but they measure different segments: with evaluation on a one-minute tick, a breach can sit undetected for most of a minute, so sub-second describes the notification path once the cron has noticed, not time-to-know ^[17].

The other thing the code shows is the cost curve. evaluateAlerts selects every enabled threshold and every host row, builds a map of hosts by id, then loops thresholds against hosts filtered in memory by tenant_id and optional host_id ^[12]. Per-tick work therefore scales with enabled thresholds multiplied by hosts, because neither read is scoped to a tenant ^[18]. At a hundred customers that is free. It is the first thing that stops being free.

The market case is coherent and specific: the author argues LATAM SMBs cannot justify observability bills that scale unpredictably with ingested logs and metrics, and cannot spare the operational skill for self-hosted alternatives, so most simply have no monitoring and learn about outages when a client calls ^[14][15]. Fixed tier pricing, Telegram as the alert channel and Spanish dashboards follow from that ^[13].

Watch two numbers neither the post nor anyone else has yet: what the bill looks like at the second and third hundred customers, and how long a cron tick takes once thresholds times hosts is a large number ^[3][18]. Watch also whether the one-minute tick quietly becomes the advertised resolution of the product ^[17].