Blog
Building notes, release changelogs, and the occasional opinion.
Why Monitoring Matters: Finding Out Before Users Do
Monitoring doesn't keep anything running — what it buys you is the interval between something breaking and you finding out, which is where almost all of an outage's cost lives. A look at the failure modes that produce no signal at all, and why a green dashboard proves less than most people assume.
Read post →v1.41: Zombie (Stuck) Job Detection
Cron monitors can now report when a job starts, not just when it finishes — set a max run duration and get a distinct alert if a job gets stuck instead of waiting on the normal missed-ping schedule. Fully opt-in: monitors that never send a start ping behave exactly as they always have.
Read post →v1.37–v1.39: DNS Record Monitoring
A sixth monitor type: watch a hostname's DNS record and get alerted the moment it changes or stops resolving — pin an expected value, or let the first check capture a baseline and alert on any later drift. Plus a couple of small internal-workflow and Codacy fixes from the two versions since the last post.
Read post →v1.40: A Second Status Page Layout
A "grid" layout joins the original single-column status page: monitors two-per-row with active incidents and history moved into a sidebar, better suited to pages watching a lot of monitors. Pick it per page from the edit form — every existing page keeps the classic layout by default.
Read post →Port (TCP) Monitoring: Beyond HTTP Checks
A database or mail server has no URL to poll, so an outage there is invisible to an uptime check. Here's how port (TCP) monitoring works, why a successful connection isn't proof the service behind it is healthy, and how to use it to catch a port that's exposed when it shouldn't be.
Read post →v1.33–v1.36: The Design Reaches the Uptime Form
Four versions since the last release notes, and the quietest stretch yet: the uptime monitor form catches up to the Claude Design rollout, two new posts landed on the blog, and a chunk of time went into how I work on this codebase rather than what it does for you.
Read post →The 3 AM SSL Cert That Cost Us a Client
A red NET::ERR_CERT_DATE_INVALID screen, six hours of bounced checkout traffic, and a client who found out from their own customers before we did. The renewal cron job had been silently failing for two months — here's why that failure is invisible until the exact second it isn't, and what actually catches it.
Read post →v1.32: Configurable Uptime Checks
Uptime monitors were always a GET request, a 10-second timeout, and exactly HTTP 200. v1.32 makes all three configurable per monitor, and collapses the existing optional response-time SLA field into the actual request timeout instead of leaving two overlapping knobs.
Read post →Uptime Monitoring: Beyond the Status Code
A 200 response isn't proof a page actually works. Here's how uptime monitoring works, why content checks beat status codes alone, and what to look for in a tool before you trust it.
Read post →Cron Job Monitoring: Catch Silent Failures
Cron jobs fail silently, not loudly. Here's how cron job monitoring — the dead man's switch — works, how to set it up in three steps, and what to check before trusting a tool with it.
Read post →Why Domains Expire Silently, Not From Negligence
A lapsed domain is rarely negligence — it's usually a boring, invisible failure chain: an expired card, a reminder email nobody reads, a WHOIS contact that hasn't been checked in years. Here's why it happens, what it actually costs when it does, and how to catch it before a client does.
Read post →v1.31: The Sitemap Was Lying, Plus Structured Data
v1.30 shipped build-time prerendering to fix a Bing crawl notice. Rather than trust the release notes, I actually curled the live site afterward — and found two more crawler-facing bugs hiding right behind it: the sitemap pointed a real blog post at a URL that didn't exist, and every marketing page cost crawlers an unnecessary redirect. Both fixed, plus Organization and SoftwareApplication structured data on the homepage.
Read post →v1.30: Teaching Bing That Checkmeup Has Content
Bing Webmaster Tools flagged the homepage for a missing h1 heading. It wasn't a markup bug — every page really does render one. The actual problem was that checkmeup is a client-rendered app, and Bingbot doesn't run JavaScript. This release fixes that properly, and closes an older, related gap along the way.
Read post →v1.28: Manual Incidents Arrive, Plus a Real Toggle
Two things landed on status pages today: you can now declare and narrate an incident yourself instead of only ever showing raw monitor up/down, and paid plans can finally turn off the "Powered by Checkmeup" footer — a feature the pricing page has quietly promised for a while.
Read post →v1.29: Incidents Get Limits, Finally
A follow-up to last release's incident management feature: resolved incidents now age out after 90 days, and every resource that could previously grow without limit — active incidents, incident updates, maintenance windows, API keys — now has a flat, plan-independent ceiling.
Read post →v1.24–v1.25: Teaching Search Engines Checkmeup
Checkmeup is a single-page app, which meant every route — the homepage, pricing, every blog post — served the exact same page title and description to search engines. These two releases fix that: real per-page metadata, a sitemap, a robots.txt, and FAQ rich-result markup, plus one honest gap that's still open.
Read post →v1.27: Checks That Reuse Connections
No new feature in this one — it's a quieter release focused on how the monitoring engine itself runs: reusing connections instead of rebuilding them on every check, giving the database pool an explicit ceiling instead of an implicit default, and cutting duplicated code out of the alert-delivery and notification-settings paths.
Read post →v1.26: A Real 404 Page, and a Name Fixed
This release closes out the SEO thread from v1.24–v1.25 with Article schema for richer blog search results, gives Checkmeup an actual 404 page instead of a blank screen for any dead link, and fixes something that's been quietly inconsistent since launch: how the product's own name gets capitalized.
Read post →v1.23: Turning the Audit on Checkmeup's Own Codebase
This release is small on the surface — you'll now see a version number in the dashboard sidebar and the site footer. Most of the week actually went somewhere you won't see directly: an audit of Checkmeup's own codebase that found six real maintainability problems, and fixed all of them.
Read post →v1.20–v1.22: The Redesign Reaches Everything Else
The marketing site got a visual redesign a while back. This week that same look — near-black/near-white neutrals, translucent surfaces, a lower-contrast palette — finally reached the parts people actually use every day: the dashboard, the public status page, and Settings/Status Pages Admin/Monitors/Maintenance.
Read post →Checkmeup vs. Healthchecks, UptimeRobot, Cronitor
Three tools get named in every 'what should I use to monitor my cron jobs' thread: Healthchecks.io, UptimeRobot, and Cronitor. Here's a feature-by-feature, dollar-by-dollar look at where Checkmeup fits — and where it honestly doesn't win yet.
Read post →v1.19: SMS Alerts, and a Real Downgrade
Checkmeup can text you now — an eighth alert channel via Twilio, with a monthly credit quota so a flapping monitor can't turn into a surprise bill. And a smaller but overdue fix: downgrading your plan used to leave every over-limit monitor running forever. Now it actually enforces the new limit — pausing the newest monitors first and keeping your oldest ones active.
Read post →v1.17: Analytics, With a Consent Banner That Counts
Checkmeup.net has had zero visibility into its own landing page and signup funnel since launch. This release adds Google Analytics 4 behind a Google Tag Manager container — but nothing loads, and nothing tracks, until a visitor actually clicks Accept. Also: a Paddle webhook race that could leave a Hobby org stuck with no way to see upgrade options.
Read post →v1.18: A Public API, So Status Isn't Dashboard-Only
Every monitor's status has lived exclusively behind the dashboard's session cookie until now. v1.18 adds a read-only public API — generate a key, send it as X-API-Key, and pull a monitor's status into a CI pipeline, an internal ops dashboard, or a physical status LED. Cron pings can now also carry their own tags (a build number, a pass/fail state), which show up in both the dashboard and the API.
Read post →v1.14: Legal Housekeeping
No new monitor type this time. A domain-verification checklist for a payment processor turned into a real audit of the Terms of Service and Privacy Policy — both had gaps worth fixing, plus a standalone Refund Policy page. A couple of Docker/registry housekeeping items rode along.
Read post →v1.15: Billing Moved to Paddle
Checkmeup's payment provider changed from LemonSqueezy to Paddle — full replacement, not a dual-provider setup. Nothing changes for existing subscribers except where the invoice comes from; the trigger was a payment processor's domain-verification checklist that surfaced Paddle as the better long-term fit before real revenue depended on either provider.
Read post →v1.16: Change Plan Without Leaving the Page
Upgrading, downgrading, and cancelling an existing subscription now happens directly on the Billing page — no re-running checkout to switch tiers. Paddle rejections surface with the actual reason instead of a generic error, and a scheduled cancellation is tracked properly instead of just hoping the UI catches up.
Read post →v1.12: Port (TCP) Monitoring
A fifth monitor type: raw TCP connect checks for non-HTTP services like mail servers and databases. It ships with a twist beyond the usual up/down check — an expected-state toggle that turns it into a security check for ports that should stay closed.
Read post →v1.13: New Homepage, New License
Two unrelated changes landed together: the homepage got a redesign — live product mockups instead of static screenshots, a proper status-page card, a cleaned-up footer — and Checkmeup's license changed from MIT to the Business Source License.
Read post →v1.11: Alert Noise Reduction
Configure how many consecutive failures must occur before the first alert fires — across all four monitor types. Pair it with the existing per-incident alert cap to control both the start and the volume of notifications for any incident.
Read post →v1.10: Slack Alerts
Slack joins Telegram, email, and webhooks as a native alert channel. Paste an Incoming Webhook URL, pick which monitors it covers, and get formatted Block Kit messages when something goes down and when it recovers.
Read post →v1.9: Status Badges and Assertion Checks
Two additions this release: embeddable SVG status badges you can drop into a README or site footer to show live monitor status, and structured assertion checks for uptime monitors — JSON field assertions and a response-time threshold that actually fail the check, not just annotate it.
Read post →v1.8: Domain Expiry Monitoring
A fourth monitor type alongside cron, uptime, and SSL: domain registration expiry. Checkmeup already told you when a certificate was about to lapse — now it tells you when the domain underneath it is about to disappear entirely, which is rarer but a lot worse when it happens.
Read post →v1.7: Webhook Alerts
A third alert channel alongside Telegram and email: webhooks. Point a monitor at any HTTPS endpoint and get a signed POST when it goes down or recovers — Slack incoming webhooks, PagerDuty, your own scripts, whatever's listening. Plus the SSRF hardening that comes with letting users hand you an arbitrary URL to request.
Read post →v1.6: Multi-Channel Notifications
The headline: monitors no longer alert through a single org-wide Telegram chat and email address — you can connect multiple channels and choose which ones each monitor uses. Plus keyword monitoring is free on every plan now, and a couple of security hardening fixes.
Read post →v1.5: Cleanup, a Plan-Limit Bug, and More Tests
Another quiet release: one real bug in how uptime monitor intervals get enforced on edit, a dark-mode color fix, a data-fetching cleanup across the dashboard, and more backend test coverage.
Read post →v1.4: A Testing Pass (and the Bugs It Found)
No new features this time. Just a deliberate pass at backend test coverage — and the handful of real bugs, including one security issue, that it turned up along the way.
Read post →v1.3: Email Alerts and Keyword Monitoring
A second alert channel alongside Telegram, and uptime monitors that can now look inside the response body. Here's what shipped in v1.3.
Read post →v1.1: Themes, Legal Pages, FAQ, and Feedback
Theme toggle, Terms & Privacy (finally), a proper FAQ page, and an in-app feature-suggestion form. Here's what changed in v1.1.
Read post →v1.2: Annual Billing and Real Upgrade Buttons
Annual plans at two months free, and the Billing page finally does something other than say "coming soon." Plus: why you still can't pay me yet.
Read post →The Cube on My Desk: Pomodoro and Building Checkmeup
A small black cube sits next to my keyboard and ticks down in 25-minute blocks. Here's what the Pomodoro Technique is, and how it shaped the pace Checkmeup got built at.
Read post →v1.0 — First Release: What Shipped and What's Next
Checkmeup v1.0 is live. Here's the complete changelog, what we deliberately left out, and a foggy look at the road ahead.
Read post →Three Days to MVP: How We Built Checkmeup
A cron monitor, uptime checks, SSL alerts, status pages, and billing — shipped in roughly 20 hours over three days. Here's what actually happened.
Read post →We use cookies for basic web analytics (page views, traffic sources). No ads, no cross-site tracking.