Observare
Bundled ops monitoring for solo devs and small agencies.
Observare is my bundled ops-monitoring SaaS (£5/month — uptime, SSL, ports, cron heartbeats, process/Docker checks via a Go agent). This week I shipped the seventh monitor type: streams. HLS playlists, DASH manifests, MP4 files.
The failure mode that made it worth building
Every stream operator has lived this one: the encoder crashes or the packager wedges, the CDN keeps cheerfully serving the last playlist it has, and every uptime check on earth stays green. The URL returns 200 OK all day. Meanwhile every viewer is watching a frozen frame.
So a plain HTTP check is worthless for streams. The check that matters is: is the playlist still advancing? Observare remembers the stream's position between checks — media sequence and newest segment for HLS, a manifest fingerprint for live DASH. Playlist still served but not moving = frozen stream = incident + alert, same as any outage.
The design constraint that shaped everything
Segment requests are indistinguishable from playback. Lots of streams have session tokens or concurrent-viewer caps, and a monitor that downloads video would either fail spuriously or count as a viewer — on some setups it would literally lock the real viewer out. So the cloud checker fetches playlist text only, never media. A playlist that keeps advancing is proof the stream is playing, and playlist fetches don't count as plays.
That constraint also settled the architecture for the deeper tier. Actually measuring video — real bitrate, black-frame detection, silent audio — means downloading and decoding segments, which is both heavy and playback-shaped. That work doesn't belong on my server, it belongs on the customer's. So deep inspection lives in the Linux agent: opt-in per monitor, runs ffprobe/ffmpeg on the customer's own hardware, and catches the truly nasty case — stream is up, segments flowing, HTTP green, and the channel is transmitting a black screen with no sound.
The split keeps my VPS doing kilobytes of text parsing while the customer's box does the video work. A £5/month product can't afford to transcode-check the world's streams centrally — and it turns out it never needs to.
Where it's at
Live now, in the same £5 bundle, 7-day trial with no card. Docs: https://observare.co.uk/docs/stream-monitoring
Happy to answer anything about the staleness detection or the agent split.
I launched Observare in April — bundled ops monitoring for solo devs and small agencies (uptime, SSL expiry, ports, cron heartbeats, a Linux agent for private networks, Stripe webhook logging, status pages). One plan, £5/month, 7-day free trial.
Four months later: zero signups.
The product wasn't the problem — I use it to monitor its own infrastructure every day. The traffic wasn't zero either. The problem was the first thing every visitor hit: a card details field on the signup form.
I'd gone card-up-front deliberately — it filters spam accounts and converts trials automatically on day 7. Standard advice. But that advice comes from companies with brand trust. Nobody hands card details to a £5/month site they found an hour ago, run by someone they've never heard of. I wouldn't either. Every argument for card-up-front assumes the visitor already trusts you; mine don't yet.
So I rebuilt the funnel:
- Signup is now name, email, password. No payment step at all — Stripe isn't even loaded on the marketing site any more.
- The trial lives in my own database, not in Stripe. A small background worker handles the lifecycle: reminder email 2 days before the end, then if there's no subscription, monitoring pauses — the account and all its config are kept.
- Card entry moved inside the product, via Stripe's hosted Checkout, at the moment someone decides to stay. Subscribe mid-trial and the remaining free days are honoured — the card isn't charged until the trial would have ended anyway.
- Expired ≠ deleted. A paused account resumes with one click, weeks later if need be. Abandoned accounts get purged on a documented schedule instead of rotting forever.
The subtle bit that took the most thought: with a hosted checkout, "user clicked subscribe" and "user actually subscribed" are different states. Someone can open the checkout page, get a Stripe customer created, then close the tab. If your code treats "has a Stripe customer" as "is a paying user", that person gets a free trial that never expires. The rule that fixed it: a user belongs to Stripe only when a subscription exists, not a customer.
Trade-off I've accepted: spam/drive-by signups get 7 days of free monitoring now. Rate limits and the purge policy cap the damage, and honestly — if the alternative filter was also filtering out 100% of real customers, it wasn't a filter, it was a wall.
The new funnel went live this week. I'll report back with whether "no card required" actually moves the number that matters.
Site: observare.co.uk — curious what other bootstrappers found when they dropped card-up-front: did trial abuse actually materialise, or is it mostly a myth at small scale?
Took a couple of months away from Observare to deal with other things. Not giving up — just life.
Came back this week and the product is in better shape than I remembered. Everything I planned to build is built: uptime, SSL, port, cron heartbeat, a Linux agent for private network monitoring, process and Docker container checks, branded status pages, five alert channels, Stripe webhook logging. All bundled at £5/month.
I'm a solo dev, engineering manager by day, and I built this because I was the target customer. I wanted one tool that did everything I needed without paying three separate subscriptions or dealing with enterprise pricing.
The hard part now isn't building — it's getting people to try it.
If you're running anything in production and you're not monitoring it properly, or you're paying too much for tools that only do one thing, I'd genuinely love for you to try it. Registrations are open at observare.co.uk.
What's bringing people back to build-in-public threads after a break? Curious if others have had the same experience of stepping away and coming back fresher.
I've been running Observare as a solo-founder monitoring SaaS for indie devs and small agencies. £5/month, bundled uptime + SSL + port + cron + webhooks + status pages. One login, one bill, no per-feature upsell. Debian VPS, founder-is-the-customer, the usual.
The positioning was always "for the kind of operator who runs their own VPSes and Docker containers." Until today, there was a contradiction in that pitch: Observare couldn't actually see inside any of that.
Your marketing site, sure — I can hit that from the cloud. But your Postgres inside a VLAN? Your Python queue worker on a VPS? The self-hosted n8n container on a homelab Pi? A Docker container on a user-defined bridge network? My servers can't route to any of that, so none of it was monitorable. I was selling a product that specifically targeted self-hosters but couldn't monitor the self-hosted parts of their stacks.
The Linux agent fixes that. One-liner install:
curl -fsSL https://observare.io/install.sh | sudo sh
It's a 6 MB static Go binary. No runtime dependencies, no inbound listener, no new firewall rules. Installs as a hardened systemd service under your regular user — not root — with NoNewPrivileges, ProtectSystem=strict, and ProtectHome=read-only.
Four monitor types, all running locally on the server you install it on:
- Internal HTTP/HTTPS — private APIs, admin panels, localhost services.
- Internal TCP/UDP ports — databases, message brokers, anything behind a VLAN.
- Process monitoring — a /proc scan for a named process.
- Docker containers — a local Docker daemon query to confirm a named container is in the running state.
Auth is a device-code flow (same pattern as the GitHub and Stripe CLIs) — observare auth prints a URL, you approve in the browser, done. Monitors are added from the CLI (observare config), but edited, paused, and wired to alert channels in the web UI. Agent-managed monitors sit on the same pages as the cloud-managed ones, marked with a small robot icon — green if the agent is online, red if it's offline.
No pricing change. £5/month covers everything — uptime, SSL, port, cron, webhooks, status pages, agent. Five agents per account, 30 monitors of each type.
No per-agent upcharge, no host license.
That finishes the original launch roadmap.
Docs: https://observare.co.uk/docs/installing-the-agent
Trial: https://observare.co.uk/register
Happy to answer questions about the Go agent side — the device-auth approach, the /proc/*/comm scanning, the Docker Unix socket check pattern, or the systemd hardening. AMA.
Observare — the bundled ops-monitoring SaaS I've finished building in public — is open. £5 a month, 7-day free trial, card required at signup.
What's in the box:
- 4 monitor types: uptime, SSL certificate expiry, port (TCP/UDP), cron heartbeats
- 5 alert channels, all included: email, SMS, Slack, Discord, generic HMAC-signed webhook
- Stripe webhook logging + replay, competitive with Hookdeck/Svix
- Branded public status pages (up to 5 per account), competitive with Statuspage.io/Instatus
- 30 monitors per type per account — 120 monitors total for a fiver
One login, one bill, one alert inbox. The pitch is dead simple: replace the four free-tier tabs you currently have pinned (UptimeRobot + certbot + Healthchecks.io + ad-hoc webhooks) with one paid account at the price of a pint.
I run the thing against itself — Observare monitors Observare, and the two public status pages it produces are open to anyone:
Those aren't mockups or demos. They're the exact feature customers get, pointed at the hosts running Observare. If the monitors catch a real outage on my infra, it'll show up there first.
Question for other indie builders launching low-price bundles: how did you decide which features to group into the launch vs hold back for post-launch? My instinct was to ship the full bundle at once because the pitch IS the bundle, but I'm curious if anyone here took a phased approach and regretted it (or the reverse).
Shipped Slack and Discord alert channels in Observare today. That makes five: email, SMS, Slack, Discord, and generic webhook. All included in the £5/month plan.
Both work the same way — you create a webhook in your platform (Slack Incoming Webhook or Discord Server Webhooks), paste the URL into Observare, and assign it to your monitors. Alerts arrive as colour-coded messages: red for down, amber for warnings, green for recovery.
We shipped both the same day because they're almost identical under the hood. Slack uses Block Kit, Discord uses embeds, but the pattern is the same: POST formatted JSON to a webhook URL. The generic webhook channel we shipped earlier this week forced us to solve the hard problems first (SSRF guard, dispatch wiring across all five monitor types, rich payloads). Slack and Discord were thin wrappers on top.
That's a pattern I'd recommend to other indie builders: ship the generic version first, then the platform-specific ones are trivial. We didn't build a Slack integration and a Discord integration — we built a webhook integration, then formatted the JSON differently for each platform.
WhatsApp is the last channel on the roadmap. Everything else — uptime, SSL, port, cron heartbeat monitoring, Stripe webhook logging, public status pages, and now five alert channels — is live and included.
-
1
Hey Michael, congrats on shipping Slack and Discord alerts, five channels all included for £5/month is really strong value!
Smart move building the generic webhook first and then layering Slack/Discord on top. That pattern is excellent advice for other indie builders.
Quick question: now that you have five alert channels live, which one are early users adopting the fastest (or requesting the most)?
Solid progress, the "everything included" positioning keeps getting stronger.
-
1
Thanks! Honest answer: I don't have real adoption data yet — I only opened signups today (literally hours ago), so "early users" are about to happen rather than already happening.
But here's what I can share from the build-in-public conversations so far: the channel that generated the most beta interest was the generic webhook, by a noticeable margin. The pattern was always "I already have PagerDuty / Opsgenie / my own internal tool wired up for ops alerts — as long as you can POST to a URL, I'm in." That's actually the reason I front-loaded the generic webhook ahead of the platform-specific ones.
On my own dogfood account (Observare monitors Observare), I've turned on email everywhere and SMS on the two or three things that would wake me up at 3am. Slack and Discord are off for me personally because I'm not in a team ops channel at this scale yet — but I expect that to flip once real customers start joining.
Let me come back to this in two weeks with actual signup data. Happy to follow up here or on the next build update if you're interested.
-
1
That makes a lot of sense, especially the webhook leading since it fits directly into existing workflows.
Interesting that you’re already using email vs SMS based on urgency, feels like that “severity → channel” mapping could become a really strong default for users as well.
Curious to see how that plays out once real usage data comes in. So yea I’m interested
-
-
Shipped public status pages in Observare today.
Each customer can create up to 5 branded status pages that show the live health of their selected monitors. Pick which monitors to display, add your logo and brand colour, choose dark or light theme, and it's live at a unique URL in seconds.
The page groups monitors by type — Uptime, SSL Certificates, Port Monitors, Cron Heartbeats — with 30-day uptime percentages and a 14-day incident timeline. Overall status (Operational / Degraded / Outage) is computed live from the individual monitors, not something you manually toggle.
What I'm most pleased with is the branding. Custom page title, logo, accent colour, dark/light theme, custom background colour. Optional password protection for teams that need a status page visible to customers but not the general public.
The public page is server-rendered HTML with inline CSS — no React, no JS framework, no external dependencies. Loads instantly. A status page is the one piece of infrastructure that has to work when everything else is broken, so the simpler it is the better.
This rounds out the bundle. Observare now covers uptime, SSL, port, cron heartbeat monitoring, Stripe webhook logging, email/SMS/webhook alerts, and public status pages — one login, one dashboard, £5/month.
The only remaining planned channels are Slack, Discord, and WhatsApp alerts.
Full docs: observare.co.uk/docs/status-pages
What does your status page setup look like? Built your own, using a hosted tool, or just hoping nobody notices when things go down?
Shipped generic webhook alert channels in Observare today.
Instead of building individual Slack, PagerDuty, Discord, and Opsgenie integrations one at a time, we built one generic webhook channel. You give us a URL, we POST structured JSON every time a monitor fires — down, recovered, flapping, SSL expiring, heartbeat missed, the lot.
One feature. Connects to everything.
PagerDuty, Opsgenie, Slack incoming webhooks, Discord webhooks, n8n, Zapier, Make, or your own custom endpoint — they all just work because they all accept HTTP POSTs.
The payload is structured with an event field (15 types across uptime, SSL, port, cron, and Stripe webhooks), a details object with event-specific data, and a short message field you can forward to a chat channel as-is. Optional HMAC-SHA256 signing if you want to verify authenticity.
This was a deliberate choice. Individual integrations are maintenance liabilities — each one has its own auth flow, its own API versioning, its own breaking changes. A generic webhook puts the customer in control. If they switch from PagerDuty to Opsgenie, they change the URL. They don't wait for us.
For a £5/month bundled monitoring tool, that felt like the right call. We're not trying to replace anyone's ops stack — we're trying to fit into it.
Included in the standard plan alongside email and SMS. No add-on pricing.
Curious what other indie builders think — do you ship individual integrations or go generic-first?
Today I'm shipping the full Observare documentation site.
Twelve pages covering every feature that's actually live: uptime monitoring, SSL expiry, TCP/UDP port checks, cron heartbeats, the Stripe webhook logger, plus account management, subscription, and support. There's a proper FAQ and a getting-started walkthrough too. Find it at observare.co.uk/docs.
The thing I want to share here isn't "look, docs!" — it's the methodology.
Every feature page is written against the actual application source. Not from memory, not from marketing copy, not from the rough picture of the product in my head. For each feature I opened the real code in one window and wrote the doc in the other. Every claim about a retention window, a check interval, a rate limit, a flapping threshold, an error category — every number and every behaviour on every page is grounded in what the code actually does.
Most small-SaaS docs don't work this way. They're written from the founder's mental model of the product, which drifts from reality the moment the codebase changes. The result is docs that are 90% right and 10% quietly wrong — and the 10% is exactly where customers lose trust.
Twelve pages. Twenty-nine real screenshots from a live test account. Honest "what isn't here yet" notes on every page for features still to come. A side benefit for me: docs are also a lever on support load — every question a customer can answer from the docs is an hour of my evening back.
Have a look: observare.co.uk/docs
Question for the room: if you've written docs for a small SaaS, are you writing them from the product or from memory? Curious whether the code-first approach is something others do or whether I'm over-engineering it.
Just shipped the first non-monitoring feature in Observare: a Stripe webhook logger and replay tool. It's in the existing £5/month plan, no upgrade needed.
What it does:
- You create webhook endpoints in your dashboard, get a unique URL to paste into Stripe
- We verify every incoming event using your signing secret, store the full payload, return 200 (so Stripe doesn't retry)
- Dashboard shows every event in real time — search by type, filter to failures, drill into the pretty-printed JSON
- Click Replay on any stored event → we POST it to your dev environment with a freshly-signed Stripe-Signature header, so your handler validates it exactly like a real event. Or switch to cURL mode and copy a runnable command instead.
- Optional alerts when signature verification starts failing — so you find out the moment your secret falls out of sync, not when the next real event breaks something downstream
The dedicated tools for this exist, but they're separate logins, separate dashboards, separate bills, and the smallest tiers start where solo devs would rather not be paying yet. Bundling it into the £5/month means it's just there when you need it.
Full writeup with the design decisions I'm proud of (parse-before-verify dedup, why we always return 200 even on signature failure, SSRF guard on replay destinations) is on the marketing site:
https://observare.co.uk/blog/stripe-webhook-logging-and-replay
Still in closed beta, taking testers via the contact form.
Comment