DEV Community: Said Ouarrak

I Built an Uptime Monitor That Does Not Wake You Up for Nothing

Said Ouarrak — Thu, 01 Oct 2026 10:56:41 +0000

I built an uptime monitoring service, and the hardest part wasn't any single feature. It was the decision to not page anyone until I'm confident something is actually broken.

The false alarm problem

Naive uptime monitoring is trivial to build. You schedule a request, you check the status code, you fire an alert if it's not 200. Ship it, and within a week you regret it.

Here's what actually happens in production:

A deploy restarts your server for 4 seconds
A shared database hiccups for one query
Someone's deploy triggers a 502 for a single request while the load balancer routes around it
A CDN edge node in a distant region times out on one TLS handshake

Each of those is a "failed check." In a naive implementation each one opens an incident, sends you a Telegram message, and wakes you up. Within a month you mute the channel. Once you mute it, the one alert that mattered — the real 40-minute outage — goes unread with everything else.

So before writing any monitoring code, the rule was:

An incident only opens after N consecutive failed checks (default: 2).

One blip is a blip. Two in a row is a pattern. That's a one-line fix that completely changes the signal-to-noise ratio.

The second half: alert on transitions, not on failures

The related mistake is alerting per failed check. If something is down for an hour and you check every 60 seconds, that's 60 messages. Meaningless.

UptimeCadet sends alerts once per state transition:

// The whole alerting rule, in spirit
const wasDown = lastStatus !== 'up';
const isDown  = currentStatus !== 'up';

if (isDown && !wasDown)  notifyDown();   // fires exactly once
if (!isDown && wasDown) notifyUp();     // fires exactly once

Down → notification. Stayed down → silence. Recovered → notification.

This is the kind of thing that seems obvious once you know it and feels like a puzzle when you don't. Worth writing down so the next person doesn't reinvent it.

What I check beyond "is it up?"

HTTP status is the baseline, but it answers a much narrower question than people expect. A monitor that only checks for 200 misses entire categories of real problems.

SSL certificate expiry. A cert that expires at 3am doesn't break anything until 3am. Then everything breaks at once. Checking the cert's not-after date days in advance turns a catastrophe into a Tuesday afternoon.

Domain expiry via RDAP. The RDAP protocol replaced WHOIS because WHOIS responses were inconsistent and often rate-limited. Domain expiry is the same class of problem as SSL — an invisible countdown that becomes total at zero.

Lighthouse page-speed scores. Now this one is a genuine tradeoff, and I'll be honest about it. Lighthouse is slow — running it on every interval would be absurd. The value isn't "your site got faster," it's directional: a score that slides from 92 to 55 over a week means you shipped something expensive. The metric is the trend, not the absolute number.

So the dashboard shows more than a green/red light. SSL, domain, and performance each get their own row.

Check interval is a plan limit, not a setting

The free plan checks every 300 seconds. Paid plans check every 60. The interval is clamped to the plan minimum server-side and capped at 3600:

requested: 10s   → clamped to 300s (Free) or 60s (paid)
requested: 7200s → capped at 3600s

This is deliberate. The interval is the single biggest driver of infrastructure cost — a monitor checked every 10 seconds across thousands of endpoints is a different product economically than one checked every 5 minutes. If the client could just request whatever it wanted, the free tier would quietly be the most expensive tier.

The docs state the actual numbers rather than "varies by plan," because a monitoring tool that hides its resolution is not trustworthy.

Passwordless login over channels you already own

There's no password. You enter your email, choose where a 6-digit code should arrive — Telegram, Slack, Discord, or email — and the code must land on a channel you already connected and verified.

The constraint that makes this safe: nothing is active until you verify it. Connect a channel, receive a 6-digit code on it, enter the code. Until then it sends nothing.

It removes a whole category of problem. No password database to breach, no reset flow to build, no "we'll email you a link" that depends on the mail provider being up. If you can receive Telegram messages, you can sign in.

Codes are single-use, expire after 10 minutes, and allow 3 attempts.

The public status API, no key required

Published status pages are exposed as read-only JSON with no account and no API key:

GET https://pulseping.xyz/api/public/status?slug=your-slug

No key is a security decision, not an oversight. Everything it returns is already public — it's the same data rendered at /status/your-slug. Anyone who can see the page can read the JSON. Adding an API key would create the illusion of protecting something that isn't secret, while adding a signing, rotation, and revocation system to maintain.

Unpublished pages return 404, so drafts can't be scraped.

This is what makes embeddable status work:

<iframe src="https://pulseping.xyz/status/your-slug" />

or a fetch against the endpoint for a live badge in your README.

Seven languages, one of them full RTL

The UI ships in English, Arabic, French, German, Spanish, Portuguese, and Turkish — with Arabic as a genuine right-to-left layout, not a mirrored stylesheet with a few flipped icons.

This is more work than it looks. dir="rtl" handles text direction, but anything positioned with physical CSS properties (left, right, margin-left) has to become logical (inset-inline-start, margin-inline-end). Icons that imply direction — a back arrow, a progress bar — need to flip. Charts need their axes reversed. It's the kind of work that's invisible when it's done right and immediately obvious when it wasn't.

Honest tradeoffs

Things I'd do differently with more time:

Checks are sequential per monitor. At high monitor counts this needs a real worker pool and concurrency limits. Right now it's fine at the scale I support.
No multi-region probing. Every check originates from one location, so a regional outage can look healthy. Real uptime services run checks from several regions and report the worst result.
Lighthouse on every interval is overkill. I check it on a slow cadence, but the scheduling deserves to be first-class rather than a special case bolted onto the checker.
Retention is unlimited and I should cap it. Every check is stored. Over years that's a lot of rows for a service charging $12/month.

Try it

UptimeCadet — free tier with one monitor, checks every 5 minutes, email alerts, no credit card. Pro is $12/month for 1-minute checks, a public status page, and Telegram/Slack/Discord alerts.

Full documentation, including the alert rules and plan limits, is at pulseping.xyz/docs.

If you find a case where this design pages you for no reason — I'd genuinely like to hear it. That's the failure mode I'm most trying to avoid.

Built by saidtechnology — a one-person studio. I build privacy-first web and mobile tools.

I Built a QR Code Generator That Never Sends Your Data Anywhere

Said Ouarrak — Thu, 01 Oct 2026 02:13:44 +0000

Most "free QR code generators" work like this: you type something, it gets sent to a server, the server encodes it and sends an image back.

That works fine. But think about what people actually encode. WiFi passwords. Contact details. URLs to internal documents. Pay-by-bank links. Sometimes literally a one-time link to something private.

If the encoder runs on someone's server, then by definition that server can read it. Even if nobody is watching. Even if the privacy policy promises not to. The data simply arrives somewhere you don't control.

What "100% client-side" actually means

When I built QR Generator, I set one rule up front: the QR encoding never leaves the browser.

No POST to an API. No POST to a serverless function. No queue that might log the payload somewhere. The input you type stays in JavaScript memory, gets turned into a matrix of modules, and is rendered into a <canvas> or an <svg> that never goes anywhere.

The app is built with Next.js (App Router, running on Turbopack), but for this particular feature "server" is almost a misleading word — the generation step is pure client-side computation. React handles the form state; everything else happens locally.

// The whole pipeline, roughly.
const qr = QRCode.create(payload, {
  errorCorrectionLevel: level,   // L / M / Q / H
  color: { dark: fg, light: bg },
});

canvasRef.current
  .getContext("2d")
  .drawImage(qr, 0, 0, size, size);

No network tab traffic. Open DevTools and watch it stay empty.

The interesting part: error correction vs. logos

QR codes have four error-correction levels. In plain terms, they trade redundancy for robustness:

Level	Redundancy	Use when
L	7%	Clean screen, plenty of room
M	15%	Default. Good all-rounder
Q	25%	Branded colors, print
H	30%	Logo overlay, printed, possibly scuffed

A logo is the interesting case, because a logo is damage. You are deliberately covering modules the scanner needs in order to read the code correctly.

So when you upload a logo, the generator bumps the error correction level automatically — the bigger your logo, the more redundancy the code needs to survive it. It's a small detail, but it's the difference between a QR code that scans every time and one that fails on a printed sticker.

PNG vs SVG, and why it matters

The other thing I care about is output quality.

PNG is what you want for screens and social posts. Raster, pixel-perfect at the size you export it.

SVG is what you want for print — a logo on a business card, a sticker, a poster. It's resolution-independent, so it stays sharp at any scale, from a 20mm sticker to a two-metre banner.

Shipping both costs nothing, and it means the tool is not forcing everyone into one compromise.

What I deliberately left out

Some things you can add that you can't take back:

No accounts. No email, no password, no "your QR codes" dashboard.
No storage. Nothing saved. Close the tab and it's gone.
No scan analytics. This is the big one, and it was a real decision.

Analytics on a QR generator are tempting — you'd learn which codes people generate, from where, and when. But the whole premise of the tool is that the payload is private. Shipping behavioral tracking alongside a privacy promise would make the promise worthless. So: none.

The honest tradeoff is that I can't tell you which features get used. I know what performs from search data and what users write to me about. That's it.

Beyond the generator

The same site runs an Android app and a fairly large guides blog covering things like when NFC is actually the better choice than a QR code, scan-rate patterns, and how to verify where a QR code points before you scan it.

That blog is a deliberate SEO play, but it's also the part I find genuinely useful — most QR content online repeats the same five steps. The interesting questions are the ones about when not to use a QR code.

Honest limitations

A few things this approach doesn't solve:

Payload size is still bounded by what a QR code can physically hold. Trying to encode a novel will not work.
On older mobile browsers, heavy payloads plus SVG rendering can feel sluggish.
"Private" means "doesn't reach my server." It does not mean "safe" — generate a QR code for something dangerous and it's still dangerous.

Try it

QR Generator — free, no signup, no watermark, PNG and SVG, runs entirely in your browser.

If you spot something broken or find an edge case I got wrong, I'd genuinely like to hear about it.

Built by saidtechnology — a one-person studio. I build privacy-first web and mobile tools.