Uptime Monit
Monitoring · by Oadbox
Know before your customers do
Uptime, performance and certificate monitoring with instant alerts and public status pages.
At a glance
- Continuous checks
- Instant alerts
- Public status pages
Built for
Product, engineering and IT teams responsible for something staying online.
Live at
uptimemonit.comThe problem
Used by whoever gets the call when something is down.
Most monitoring checks that a homepage loads, which it will do even when the database is gone — and says nothing about the certificate expiring or the nightly backup that has failed silently for six weeks.
Uptime Monit watches the endpoints your business depends on and tells you the moment one stops behaving — not when a customer emails to say the site is down.
Checks run continuously, alerts reach the right person on the channel they actually read, and a status page keeps everyone else informed without a single support ticket.
Unverified copy — uptimemonit.com was unreachable when this page was written, so the detail here describes the category rather than the shipped product. Correct it in src/lib/products.ts.
One incident on Uptime Monit
One outage, minute by minute
Monitoring gets bought for the dashboard and judged on one night. This is where Uptime Monit sits — from the first failed check at 2 am to the post-mortem the next morning.
What we counted first
Uptime Monit began the way every Oadbox product does — running our own services and sitting with small engineering teams through the nights they would rather forget. Four numbers kept coming back:
7 in 10
Outages a customer found first
The incident arrived as an email or a message from someone who had already tried to buy something and failed.
4 hrs
Until someone noticed at night
An outage that began after midnight ran until the first person woke, made coffee and opened a laptop.
1 in 3
Teams with a lapsed certificate
Roughly a third of the teams we sat with had lost an afternoon to a certificate nobody owned. Each one had a calendar reminder, snoozed.
40+
Messages asking if it's down
During a public incident the same question arrived by email, chat and phone, answered one at a time by whoever was nearest.
Counted across our own services and our early visits to small engineering teams, before Uptime Monit existed. Every team differs — your numbers are the first thing we ask about.
- 02:11
The quiet hours
Nobody is awake. Twelve checks run against the marketing site, the API, the payment service and the mail server — HTTP, keyword, port and ping, running continuously the way they have for months. The founder is asleep; so is the engineer on call.
- 02:14
A check fails
The keyword check on the checkout page stops finding the word it looks for. The next run says the same, and the one after that — not a blip and not a slow response, but a page that has quietly stopped serving what it should. An incident opens at 02:14.
- 02:15
The phone buzzes
A minute later the alert is out — SMS and WhatsApp to the engineer on call, email to the founder, a webhook into the team's own channel. A phone buzzes on a bedside table in a dark room. Somebody is awake now, and for once it is not a customer.
- 02:22
The status page
The engineer marks checkout as down and writes two lines on the status page: we can see it, we are looking. Anyone trying to pay at that hour gets an honest answer instead of a spinner. The support inbox, which used to fill up first and loudest, stays empty.
- 02:41
Back to green
The engineer rolls the change back and the keyword check passes again on the next run. Uptime Monit closes the incident and sends the recovery note on the same channels, so the founder wakes to something already resolved rather than something still burning. Twenty-seven minutes, start to finish.
- Next morning
The post-mortem
The team sits down with a timeline nobody had to reconstruct — first failed check, alert sent, status page updated, recovery, each with a time against it. The half-hour argument about when it actually started never happens. What is left is why, which is the only part worth a meeting.
- Two weeks later
The quiet warning
No outage this time. A certificate on the API has fourteen days left, and the warning arrives on a Tuesday afternoon, when renewing it is a ten-minute job rather than an emergency. The calendar reminder somebody set last year, and snoozed twice, is no longer holding the site up.
What quietly disappears
None of this is dramatic. It is the same bad night — minus the artefacts everyone had learned to live with.
The customer email asking 'is your site down?'
The calendar reminder for certificate renewal
The manual refresh to check whether we are up
The 3 am status update written from scratch
The argument about when the outage actually began
Key workflows
What it actually runs.
Multiple check types
HTTP, keyword, port and ping checks covering websites, APIs and services.
Certificate and domain expiry
Warnings well before an SSL certificate or a domain quietly lapses.
Instant alerting
Notifications by email, SMS, WhatsApp and webhook the moment a check fails.
Incident timelines
Every outage recorded with duration, cause and recovery, ready for a post-mortem.
Status pages
Public or private pages that keep customers informed during an incident.
Response-time history
Latency trends and uptime percentages measured against your SLA.
Why Oadbox
We know the industry
Uptime Monit was designed inside monitoring operations, not adapted from a horizontal tool.
It runs on our core
Tenancy, permissions, statutory compliance, offline mobile and audit trails are inherited, not rebuilt for each product.
Inside the platformWe still operate it
The team that built Uptime Monit runs it — monitoring, support, releases and the next version.
How we workMore from Oadbox
11 other products, same foundation.
Want to see Uptime Monit on your own data? That is the only demo worth having.
Thirty minutes with someone from the product team — how you work today, and an honest answer on whether this fits.