About

What this is, and why it is free

Every project I have worked on needed some of the same small pieces. Something to notice when a nightly job stops running. Something to call a URL on a schedule, in the right timezone. A lock, so two instances do not both do the work. One value I can change without a deploy. A counter. None of them is hard. All of them are fiddly, and I have written each one more than once, in a hurry, slightly wrong.

So I wrote them again with tests, and put them behind an HTTP endpoint on infrastructure that does not need me awake. Take a key and use them.

curl -X POST https://pulse.nano-api.com/v1/signup \
  -H 'content-type: application/json' -d '{"email":"you@example.com"}'

Why it is free

Charging is a promise. It commits me to a response time and an uptime I cannot hold down alongside a day job, and I would rather give you something useful with stated limits than something priced with vague ones. The infrastructure costs about five dollars a month whether anyone uses it or not.

If that changes: an email well before anything costs money, nothing switched off without you agreeing first, and no change to the shape of the API. Billing is not a reason to break a client.

How it is built

One Cloudflare Worker, one D1 database, one cron trigger firing every minute for the sweep. No VM, no container, no queue. That is the reason a free tier is possible at all: there is nothing running when nobody is calling.

Keys are stored as SHA-256 hashes, never in clear text, and you rotate and revoke them yourself. A key is full access or read-only, fixed at creation, and the read ones cannot issue wider ones. Where correctness depends on two callers not colliding, it is a single SQL statement with a WHERE that only one of them can satisfy, verified with twenty parallel requests in a test rather than asserted on a page. The code is on GitHub, including the parts I got wrong first.

Limits

Technical, not commercial. They stop one account taking the service down for everyone.

5 monitors, schedules, configs or counters to start. Ask and it goes up; it is one integer on your user row and it costs nothing.
The quota gates creating things. Pings and scheduled runs for things that already exist are never refused for quota reasons, because a billing state should not be able to switch off your monitoring quietly.
Ping payloads 2 KB. Scheduled request bodies 8 KB.
Scheduled calls: 60s timeout, 3 attempts, public HTTPS targets only.
100 distinct lock names, lease up to an hour.
Three signups per address per hour.

Before you rely on it

How fast will I know something broke?

The sweep runs every minute, so an alert lands within about a minute of the deadline. In practice I measured 9 seconds past due on a 120-second window. If you need second-level precision, this is the wrong tool and I would say so.

Where do alerts go?

Any HTTPS webhook. The body has text at the top level, which is what a Slack incoming webhook expects, so Slack needs no mapping. Email and SMS are not built.

Is there a dashboard?

One, read-only, at dash.nano-api.com. It has no login: you paste a key, because the key is already the account. Sessions, CSRF and a password reset flow are three things I would build badly, so there are none.

It insists on a key with scope: read and refuses one that can write. That is the point of it. Everything else is still the API and the curl walkthrough.

What if the service itself goes down?

Then you are not monitored, and there is no SLA to point at. Where a missed alert would genuinely hurt, run two providers. I would tell a friend the same thing.

Do you look at my data?

No. Delete a monitor and it is gone, including its ping log and events. There is no analytics script on this site.

Who

One person, evenings and weekends, in Norway. Bugs, questions and things I have got wrong go to hello@nano-api.com or @gautes.