About Vivere
A monitoring service for scheduled jobs, built in about a week, written almost entirely by an AI agent and operated by one person.
What it is
Vivere watches for the thing that does not happen. You give a scheduled job a URL to call when it finishes; if the call does not arrive on time, you are told. It also does ordinary HTTP uptime checks, publishes a status page, keeps run logs and exit codes, and exposes a JSON API and an MCP server so agents can manage their own monitors.
The idea is not new — Healthchecks.io has done it well for a decade. Vivere's bet is a particular combination: heartbeats and uptime checks together, a status page on every plan, and flat pricing for people who have many small jobs rather than a few critical ones.
Who runs it
Nicholas Bergesen, one person, in his own time. There is no company behind this, no investors and no team. Email hello@vivere.dev and he reads it.
That is worth knowing before you depend on it. It means support is a person rather than a queue, and it also means there is no on-call rotation. What that buys you: the free plan is not a funnel that gets worse, and the price is not going to double after a funding round that is never going to happen.
How it was built
Almost all of the code, the copy on this site and the infrastructure work was done by Claude, an AI agent, working in sessions with Nicholas reviewing and deciding. He does the things an agent cannot: he owns the accounts, he approves what goes out, and he answers for it.
We mention this for two reasons. It is true, and hiding it would be the sort of thing that makes people distrust everything else on a page. And it is relevant to what Vivere is for: scheduled agents that run unattended are exactly the kind of job that fails silently, and we run several ourselves.
What that does not mean: nothing here is unreviewed. Every change goes through tests, a pull request and a human decision to merge. The parts that touch money, mail and DNS were each verified on the wire before being called done.
How it runs
One Go binary and a SQLite database in one container, on one small server, behind nginx. It uses about 13 MB of memory. The whole thing is deliberately boring: no queue, no cache tier, no orchestrator, nothing that can fail on its own.
Two consequences you should weigh honestly. There is one of everything, so an outage of that machine is an outage of Vivere; a monitoring service that goes down does not alert you about the job it stopped watching. And uptime checks run from one location, so they cannot distinguish "the site is down" from "the route from here is down". If either matters more to you than the rest of the product, say so and choose accordingly — we would rather you picked the right tool than churned in a month.
The database is dumped nightly and copied weekly to a separate disk on the same host. That is a real backup against losing the database and is not an off-site backup: if the machine itself is destroyed, the copies go with it. Fixing that is on the list, and until it is, you should know it. An external uptime check runs every quarter of an hour from GitHub's infrastructure, so at least the failure of the failure-detector is noticed by something that is not the failure.
Money
Vivere charges $9 or $29 a month, through Polar as merchant of record, which means they handle payment, invoicing and sales tax. Card details never touch this server. The free plan exists because ten monitors is genuinely enough for most people's entire crontab, and we would rather be useful to a lot of people than extract the maximum from a few.
What we will not do
- Fake reviews, fake testimonials, fake user counts or invented case studies. If a number appears on this site it is measured.
- Comparison pages that never recommend a competitor. Ours say when the other tool is the better answer, because sometimes it is.
- Cold email, scraped contact lists, or posting under a name that is not a real person's.
- Third-party analytics or advertising scripts. Page views are counted by this server with no IP or user agent stored — see the privacy page, which describes it exactly.
Last updated 11 September 2026.