Building Trust Through Transparency: Why Mifugo Added a Public Status Page

Mon, 10 Aug 2026 06:08:54 +0000

Building Trust Through Transparency: Why Mifugo Added a Public Status Page

When you're building software for farmers, you're building software for people whose livelihood depends on it. A feed log missed at 6 AM isn't just a UI bug; it's a real cost. A sales entry that fails to save during market hours isn't a minor inconvenience; it's lost revenue.
That's the lens through which we build Mifugo, our livestock management platform for small-scale Kenyan farmers. And it's why, when it came time to pick a monitoring and status-page solution, we made a very deliberate choice.

The Trust Problem

Here's a scenario we take seriously: a farmer opens Mifugo at 7 AM to log yesterday's egg collection. They get a 502. They can't enter their data. They assume the app is broken and switch to a notebook. Three weeks later, they're still using the notebook.
For a SaaS product serving users on unreliable networks, perceived reliability is as important as actual reliability. If users don't know whether an outage is real or just a blip, they lose confidence. A public status page flips that dynamic: instead of farmers assuming the app is broken, they see "Incident: Database migration in progress, ETA 45m" and know to check back.

Choosing Better Stack Over Cronitor

Mifugo spans six web products plus an API health endpoint, so we needed seven uptime monitors. We evaluated the two obvious candidates: Better Stack (formerly Better Uptime) and Cronitor.
Scale first. Cronitor's free tier maxes out at 5 monitors. Better Stack's free tier includes 10. For our seven monitors, Better Stack covers us entirely at no cost. Cronitor's next tier starts at $5 per monitor per month; $35/month minimum before adding users.
Bundled value matters. Better Stack's free tier includes uptime monitoring, a public status page, email and Slack alerts, incident timelines, and on-call scheduling. Cronitor charges separately for equivalent features or doesn't include observability like logs and traces. For a growing platform, Better Stack is the more coherent choice.
The UX seals it. Better Stack's status page templates are genuinely good out of the box. Customizing ours to match Mifugo's forest-green brand (#40916c) took minutes, not hours.

What We Built

We integrated Better Stack across all Mifugo products by adding a live status indicator in every user-facing footer. The indicator links directly to status.mifugo.app and updates in real time.
The integration covers:

The marketing landing page footer
The authenticated farm app's public footer
The sign-in page header
A clickable green status dot that always lets users investigate an issue without hunting for the right link

Design Decisions

Three deliberate choices shaped our implementation:
1. The Status Indicator Should Be Alive, Not Static
Before Better Stack, the landing footer had a green dot and "All systems operational" text, but it wasn't clickable. That's a missed opportunity. A status indicator that can't be investigated becomes wallpaper. We made it clickable so one tap takes users directly to the status page.
2. The Link Should Be Everywhere a User Might Look
A farmer encountering an issue should find the status page in under two seconds, whether they're on the sign-in page, the app, or the landing site. We added System Status links across all public-facing surfaces so there's no hunting.
3. Environment Variables Should Have Safe Defaults
The status page URL defaults to https://status.mifugo.app when unset. This means the links work in local development without any configuration, and a missing deployment env var won't break the footer - it just falls back to production. Small detail, zero friction.
The Bigger Picture: Observability as a Feature
This work is small in lines of code but represents a shift in how we think about platform health.
For the first few months, Mifugo's reliability was a silent assumption. If things were working, users didn't think about it. If things broke, they filed feedback or switched to pen and paper. A public status page changes that relationship: we're no longer asking users to trust that we're reliable; we're showing them.
And for the engineering team, Better Stack's alerting means we know about incidents before the first support email arrives. The Slack integration fires the moment a monitor goes down, not when a farmer tweets about it.

What's Next

If you're building a product where downtime has real-world consequences- farmers missing feed logs, clinics missing patient entries, logistics teams missing dispatch updates- a public status page isn't overhead. It's part of the product.
Check out Mifugo at mifugo.app and the status page at status.mifugo.app.

Mifugo is built with Next.js, Mantine, Ionic React, Supabase, and Prisma, and a lot of empathy for the people who actually use it.

uptimepage

Tue, 30 Jun 2026 17:20:37 +0000

Uptimepage is an open-source uptime monitor and status page, built as one self-contained Rust binary backed by Postgres and ClickHouse. Run it with docker compose up, or use the free hosted tier.

I built it because I wanted a monitor I could run as a single binary and drive entirely as code, without operating a fleet of services to do it.

What it does

Checks: HTTP, TCP, DNS, TLS-certificate expiry, and domain expiry, from one region or many.
Public status page: HTML, JSON, and RSS, per-component opt-in, incidents, maintenance windows, email and webhook subscribers.
Alerting across about fourteen channels: Slack, generic signed webhooks, Telegram, WhatsApp, SMS, PagerDuty, ntfy, Pushover, Discord, Google Chat, MS Teams, email. Fire once, recover, and repeat until acknowledged.
Incidents with a separate internal state and public phase, so you can work an incident before you publish anything.
Multi-region probes: each agent is the same binary in a stateless probe mode. Run your own anywhere with an org-scoped token.
Automation: REST API with an OpenAPI spec, a Terraform provider, and an MCP server an LLM client can query over OAuth.

A few engineering bits

A custom hyper and rustls client instead of a high-level one, so each result carries separate DNS, connect, TLS, and TTFB timings. About 130K checks a second on one core in the load test.
A single min-heap scheduler for the whole fleet rather than a timer task per monitor, so memory stays flat in fleet size.
ClickHouse with per-row TTL and minute and hour rollups, so dashboards never scan raw rows.

Full write-up of how it is built: https://uptimepage.dev/blog/building-an-uptime-monitor-in-rust

Free and open

The core is not paywalled. Checks, status pages, subscribers, the API, and every alert channel are in the free tier, with no card to start. It is AGPL-3.0, and it monitors itself.

Site and hosted tier: https://uptimepage.dev
Source: https://github.com/uptimepage/uptimepage

Happy to answer questions about the internals or the self-host setup in the comments.

Coder Legion - Recent posts tagged status-page

Building Trust Through Transparency: Why Mifugo Added a Public Status Page