Forem: boop dev

Passkeys in Production: Adding WebAuthn to a SaaS

boop dev — Sun, 18 Jan 2026 12:39:07 +0000

Passkeys in Production: Adding WebAuthn to a SaaS

Passwordless authentication with Face ID, Touch ID, and security keys

Passwords are a liability. Users reuse them. They get phished. They forget them and reset them constantly.

Passkeys are the future: cryptographic credentials stored on your device, unlocked with biometrics. No password to steal. No password to forget.

Here's how we added passkey support to Boop.

What Are Passkeys?

Passkeys use the WebAuthn standard. Instead of a password, your device stores a cryptographic key pair:

Private key: Stays on your device, never leaves
Public key: Stored on the server

To log in, your device signs a challenge with the private key. The server verifies the signature with the public key. No shared secrets.

┌─────────────┐                      ┌─────────────┐
│   Device    │                      │   Server    │
│             │                      │             │
│  Private ───┼── Signs challenge ──▶│   Public    │
│    Key      │                      │    Key      │
│             │◀── Verified! ────────┼─            │
└─────────────┘                      └─────────────┘

The Stack

We use:

@simplewebauthn/browser - Client-side WebAuthn API wrapper
@simplewebauthn/server - Server-side verification
Redis - Temporary challenge storage
Prisma - Passkey credential storage

Registration Flow

Step 1: Generate Registration Options

// GET /api/passkey/register/options
export async function GET() {
  const session = await getServerSession(authOptions);
  const user = await prisma.user.findUnique({
    where: { email: session.user.email },
    include: { passkeys: true },
  });

  const options = await generateRegistrationOptions({
    rpName: "Boop.one",
    rpID: new URL(process.env.NEXTAUTH_URL).hostname,
    userID: new TextEncoder().encode(user.id),
    userName: user.email,
    userDisplayName: user.name || user.email,
    // Don't require attestation
    attestationType: "none",
    // Prevent re-registering existing passkeys
    excludeCredentials: user.passkeys.map((pk) => ({
      id: pk.credentialId,
      transports: pk.transports,
    })),
    // Prefer platform authenticators (Face ID, Touch ID)
    authenticatorSelection: {
      residentKey: "preferred",
      userVerification: "preferred",
    },
  });

  // Store challenge for verification
  await storeWebAuthnChallenge(user.id, options.challenge);

  return NextResponse.json(options);
}

Step 2: Browser Creates Credential

// Client-side
import { startRegistration } from "@simplewebauthn/browser";

const optionsRes = await fetch("/api/passkey/register/options");
const options = await optionsRes.json();

// This triggers Face ID / Touch ID / Security Key prompt
const credential = await startRegistration(options);

// Send credential to server
await fetch("/api/passkey/register/verify", {
  method: "POST",
  body: JSON.stringify({ credential, name: "MacBook Pro" }),
});

Step 3: Verify and Store

// POST /api/passkey/register/verify
export async function POST(request: Request) {
  const { credential, name } = await request.json();

  // Retrieve the challenge from Redis
  const expectedChallenge = await getAndDeleteWebAuthnChallenge(user.id);

  // Verify the registration
  const verification = await verifyRegistrationResponse({
    response: credential,
    expectedChallenge,
    expectedOrigin: process.env.NEXTAUTH_URL,
    expectedRPID: rpID,
  });

  if (!verification.verified) {
    return NextResponse.json({ error: "Verification failed" }, { status: 400 });
  }

  // Store the passkey
  await prisma.passkey.create({
    data: {
      userId: user.id,
      credentialId: credential.id,
      publicKey: Buffer.from(verification.registrationInfo.credential.publicKey)
        .toString("base64url"),
      counter: verification.registrationInfo.credential.counter,
      deviceType: verification.registrationInfo.credentialDeviceType,
      backedUp: verification.registrationInfo.credentialBackedUp,
      transports: credential.response.transports || [],
      name: name || null,
    },
  });

  return NextResponse.json({ success: true });
}

Database Schema

model Passkey {
  id           String   @id @default(cuid())
  userId       String
  credentialId String   @unique
  publicKey    String   // Base64url encoded
  counter      Int      // Replay attack protection
  deviceType   String   // "singleDevice" or "multiDevice"
  backedUp     Boolean  // Is credential backed up (iCloud, etc)?
  transports   String[] // ["internal", "usb", "ble", "nfc"]
  name         String?  // User-friendly name
  createdAt    DateTime @default(now())
  lastUsedAt   DateTime?

  user User @relation(fields: [userId], references: [id])
}

Challenge Storage in Redis

Challenges are one-time use with a 5-minute TTL:

export async function storeWebAuthnChallenge(
  userId: string,
  challenge: string
): Promise<void> {
  await redis.set(
    `webauthn:challenge:${userId}`,
    challenge,
    "EX", 300  // 5 minute expiry
  );
}

export async function getAndDeleteWebAuthnChallenge(
  userId: string
): Promise<string | null> {
  const key = `webauthn:challenge:${userId}`;
  const challenge = await redis.get(key);
  if (challenge) {
    await redis.del(key);  // One-time use
  }
  return challenge;
}

Authentication Flow

Similar to registration, but uses startAuthentication instead:

// Client
const options = await fetch("/api/passkey/auth/options").then(r => r.json());
const assertion = await startAuthentication(options);
await fetch("/api/passkey/auth/verify", {
  method: "POST",
  body: JSON.stringify({ assertion }),
});

Counter Verification (Replay Protection)

Each passkey has a counter that increments with every use. If we see a lower counter than expected, the credential may have been cloned:

// During authentication verification
if (verification.authenticationInfo.newCounter <= storedCounter) {
  // Possible credential cloning attack!
  throw new Error("Counter too low - possible replay attack");
}

// Update stored counter
await prisma.passkey.update({
  where: { id: passkey.id },
  data: { counter: verification.authenticationInfo.newCounter },
});

User Experience

Managing Passkeys

Users can register multiple passkeys (one per device) and name them:

{passkeys.map((passkey) => (
  <div key={passkey.id}>
    <span>{passkey.deviceType === "platform" ? "📱" : "🔑"}</span>
    <span>{passkey.name || "Unnamed Passkey"}</span>
    <span>Added {formatDate(passkey.createdAt)}</span>
    <button onClick={() => deletePasskey(passkey.id)}>Remove</button>
  </div>
))}

Device Type Icons

📱 Platform authenticator (Face ID, Touch ID, Windows Hello)
🔑 Cross-platform (USB security key, NFC)

Tracking Last Used

Update lastUsedAt on every successful authentication:

await prisma.passkey.update({
  where: { id: passkey.id },
  data: { lastUsedAt: new Date() },
});

Security Considerations

1. Origin Validation

Always verify the origin matches your domain:

expectedOrigin: process.env.NEXTAUTH_URL,
expectedRPID: new URL(process.env.NEXTAUTH_URL).hostname,

2. No Attestation Required

We use attestationType: "none" because:

Attestation adds friction
We don't need to verify the authenticator model
Privacy: attestation can fingerprint devices

3. Challenge Expiry

Challenges expire after 5 minutes and are single-use (delete after retrieval).

4. Multiple Passkeys

Users should register passkeys on multiple devices. If they lose their phone, they can still log in with their laptop.

Fallback: Traditional Auth

Passkeys are additive. Users can still log in with email/password if they haven't set up passkeys. We show passkey login first if they have any registered:

const hasPasskeys = user.passkeys.length > 0;
if (hasPasskeys) {
  // Show "Sign in with Passkey" button first
} else {
  // Show email/password form
}

The Results

Since adding passkeys:

50% of active users have registered at least one passkey
Zero password-related support tickets from passkey users
Login is faster (biometric vs typing password)
Phishing-proof (passkeys are origin-bound)

Lessons Learned

Use a library - Don't implement WebAuthn from scratch. SimpleWebAuthn handles the edge cases.
Store challenges in Redis - They need to be ephemeral and accessible across requests
Track device type - Users want to know which passkeys are on which devices
Allow multiple passkeys - One per device is the expected pattern
Keep password fallback - Not everyone has a compatible device

Passkeys are the best authentication UX that also happens to be the most secure. Your users just need to look at their phone or touch their laptop.

Passwordless authentication at Boop

How We Monitor Internal Services Without Opening Firewall Ports

boop dev — Sat, 17 Jan 2026 11:31:43 +0000

How We Monitor Internal Services Without Opening Firewall Ports

Most uptime monitors only watch what's publicly accessible. But your database, internal APIs, and microservices? Those stay invisible until something breaks and a user complains.

We built private agents to solve this. Here's how they work and why they're different.

The Problem with Monitoring Internal Services

Your internal infrastructure is behind a firewall for good reason. But that creates a monitoring blind spot:

Databases - Is your PostgreSQL replica in sync?
Internal APIs - Is your auth service responding?
Microservices - Is that background worker healthy?
Private networks - Are your VPC endpoints working?

Traditional solutions either require:

Exposing services to the internet (security nightmare)
Expensive enterprise monitoring ($95+/month per agent)
Self-hosting complex monitoring stacks

We wanted something simpler.

How Private Agents Work

A private agent is a lightweight Docker container that runs inside your network. It monitors your internal services and reports back to Boop.

┌─────────────────────────────────────────────────────┐
│                  Your Network                        │
│                                                      │
│   ┌─────────┐    ┌─────────┐    ┌─────────┐        │
│   │Database │    │ API     │    │ Service │        │
│   │ :5432   │    │ :8080   │    │ :3000   │        │
│   └────┬────┘    └────┬────┘    └────┬────┘        │
│        │              │              │              │
│        └──────────────┼──────────────┘              │
│                       │                             │
│                ┌──────┴──────┐                      │
│                │   Boop      │                      │
│                │   Agent     │                      │
│                └──────┬──────┘                      │
│                       │                             │
└───────────────────────┼─────────────────────────────┘
                        │ HTTPS only (outbound)
                        ▼
                 ┌─────────────┐
                 │  boop.one   │
                 └─────────────┘

The key insight: outbound only. The agent connects to Boop - Boop never connects to you. No inbound firewall rules. No VPN tunnels. No exposed ports.

Setup in 60 Seconds

Create an agent in your Boop dashboard
Copy the setup token (valid for 24 hours)
Run the container:

docker run -d \
  --name boop-agent \
  -e BOOP_SETUP_TOKEN=your_token_here \
  -v boop-data:/data \
  boopone/agent:latest

That's it. The agent automatically:

Exchanges the setup token for a secure active token
Pulls monitor configurations from Boop
Starts checking your internal services
Reports results back to your dashboard

The Buffer: Never Lose Data

Here's where it gets interesting. What happens when your network has an outage? Or the agent temporarily loses connectivity to Boop?

Most monitoring tools just... lose that data. You get gaps in your graphs and no idea what happened.

We built a buffer into the agent.

How the Buffer Works

When the agent can't reach Boop:

It keeps running checks using cached configuration
Results are stored locally in a persistent buffer
Each result gets a timestamp and unique ID

When connectivity returns:

The agent submits all buffered results
Boop processes them with their original timestamps
Your monitoring history stays complete

Timeline:
────────────────────────────────────────────────────►

[Normal]     [Disconnected]     [Reconnected]
   │              │                   │
   │   Agent      │   Agent buffers   │   Buffer syncs
   │   reports    │   results locally │   to Boop
   │   live       │                   │
   ▼              ▼                   ▼

   📊             💾                  📊
   Live data      Stored locally      Historical data
                  (up to 10,000       restored
                   results)

Smart Alert Handling

Here's the clever part: buffered results don't trigger alerts.

Think about it - if your agent was offline for 30 minutes and buffered 50 check results, you don't want 50 alert notifications flooding your Slack when it reconnects. Those results are historical. The situation has either resolved itself or you've already noticed.

So Boop:

Records all buffered results for your historical data
Updates your uptime graphs accurately
Does NOT fire alerts for old data
Marks them as "buffered" so you know what happened

What Makes This Different

1. Price

Most competitors charge $95/month or more for a single private agent. We start at $7/month.

Provider	Cost per Agent
Competitors	$95+/month
Boop	$7/month

That's 93% cheaper. Not a typo.

2. Security Model

Setup tokens expire in 24 hours (one-time use)
Active tokens auto-rotate every 7 days
All communication is outbound HTTPS only
No credentials stored on the agent

3. Full Feature Parity

Private agents support everything public monitoring does:

HTTP/HTTPS checks with status code and keyword validation
DNS lookups
TCP port checks
SSL certificate monitoring
Custom headers and authentication

4. Resilience

The buffer means your agent survives:

Network blips
DNS issues
Temporary firewall problems
Boop maintenance windows

You never lose monitoring data.

Real-World Use Cases

Startup with hybrid infrastructure:
Monitor your AWS RDS database, internal auth API, and Redis cache - all from one agent, one dashboard, one alerting pipeline.

Agency managing client servers:
Drop an agent on each client's network. Monitor their internal services without requiring them to expose anything to the internet.

Enterprise with compliance requirements:
Keep sensitive infrastructure completely internal while still getting modern monitoring and alerting.

Try It

Private agents are available on all paid plans:

Starter ($7): 1 agent
Hobbyist ($15): 2 agents
Professional ($79): 10 agents
Enterprise plans: 25+ agents

Set one up at boop.one. The agent is open source if you want to see exactly what it does before deploying.

Have questions about monitoring internal infrastructure? I'm happy to help - drop a comment below.

Why We Made Our Monitoring Stats Public

boop dev — Fri, 16 Jan 2026 20:05:20 +0000

Why We Made Our Monitoring Stats Public

Most monitoring services hide their numbers. We decided to do the opposite.

At boop.one/live, you can see exactly how Boop is performing right now - checks per minute, regional latency, success rates, everything. No login required.

What You Can See

The live dashboard shows real-time stats from our monitoring infrastructure:

Global Numbers

Checks per minute (currently ~150)
Total checks in the last 24 hours (330,000+)
Active monitors across the platform
Incidents detected in the last 24 hours

Regional Performance
We run checks from 4 regions, and you can see each one:

US-East (Virginia)
US-West (Los Angeles)
EU-Central (Frankfurt)
Asia-Pacific (Singapore)

For each region, we show:

Number of checks performed
Average response time
Success rate percentage

Additional Metrics

SSL certificates being monitored
Average days until certificate expiration
DNS success rates
Platform uptime percentage

Why Make This Public?

1. We Should Practice What We Preach

We are a monitoring company. If we are going to tell you that uptime matters, we should be willing to show ours.

Hiding our stats while asking you to trust us with yours felt hypocritical.

2. It Demonstrates Scale

Anyone can claim they handle "millions of checks." Showing real numbers proves it.

When you see 330,000+ checks in the last 24 hours updating in real-time, you know it is not marketing fluff.

3. It Builds Trust

Before you sign up for a monitoring service, you probably want to know:

Is it actually reliable?
Does it work globally?
Can it handle scale?

Our live page answers all of these without you having to trust our marketing copy.

4. It Keeps Us Honest

When your stats are public, you cannot hide problems. If our success rate drops, everyone sees it.

This creates internal pressure to maintain quality. We are not just accountable to paying customers - we are accountable to anyone who visits the page.

The Technical Side

The live stats page pulls from a public API endpoint that aggregates data from our monitoring infrastructure:

Check counts come from our job queue metrics
Response times are averaged from recent check results
Success rates are calculated from the last hour of data
Regional breakdowns use our multi-region worker data

The page refreshes every 15 seconds, so you are seeing near-real-time data.

What We Learned

Publishing our stats publicly changed how we think about reliability. When a metric looks bad on the dashboard, we feel it immediately.

It also became an unexpected marketing tool. Developers appreciate transparency, and the live page has driven signups from people who just wanted to see what we were about.

See It Yourself

Check out the live dashboard: boop.one/live

Watch the numbers update in real-time. See which regions are fastest. Notice how many checks we are running right now.

And if you want that kind of visibility for your own infrastructure, Boop includes public status pages so you can give your users the same transparency.

What metrics would you want to see from a monitoring service? Drop a comment below.

How I Use Claude to Watch My Infrastructure While I Sleep

boop dev — Thu, 15 Jan 2026 16:32:55 +0000

How I Use Claude to Watch My Infrastructure While I Sleep

Running a monitoring service means your infrastructure can't go down. The irony isn't lost on me - if Boop goes offline, nobody gets alerted that their own services are down.

Our customers rely on us to watch their websites, APIs, and servers 24/7. When their infrastructure has a problem at 3am, we're the ones who wake them up. That only works if we're awake ourselves.

So I built something a little unusual: I have Claude running every 30 minutes, checking on everything, and fixing problems automatically. Here's how it works and why I can actually sleep at night.

The Problem: Alert Fatigue vs. Missing Real Issues

Traditional monitoring has two failure modes:

Too many alerts - You get paged for every blip, eventually ignore them all
Too few alerts - You miss the one that matters until a user complains

I wanted something smarter. Not just "send me an alert" but "diagnose the problem and fix it if you can."

The Setup: Claude as an On-Call Engineer

Every 30 minutes, a cron job runs a health check script. But instead of just checking metrics and sending alerts, it hands off to Claude with a simple mission:

Check everything. If something's broken, fix it.

Here's what Claude actually does:

Checks Fly.io machine status - Are all 4 regions running?
Hits the health endpoint - Is the API responding?
Reviews recent logs - Any errors or warnings?
Checks queue depth - Is work backing up?
Diagnoses issues - What's actually wrong?
Fixes what it can - Restart machines, deploy fixes, push code changes

claude -p "Do a health check on boop infrastructure..." \
    --allowedTools "Bash,Read,Edit,Write,Grep,Glob" \
    --permission-mode bypassPermissions

What Claude Can Actually Fix

When Claude finds a problem, it doesn't just report it. It acts:

Machine down? Restart it:

fly machine start <machine-id> -a boop-monitor

Need a redeploy? Deploy it:

fly deploy -a boop-monitor

Code bug causing issues? Fix and push:

# Edit the problematic code
# Run npm run build to verify
git add -A && git commit -m "Auto-fix: improve queue handling" && git push

The CI/CD pipeline automatically deploys code changes. I wake up to an email saying "Fixed a bug while you slept."

The Contention Problem

Here's where it gets tricky. What happens when:

I'm actively coding and have uncommitted changes?
A GitHub Action is deploying?
Another health check is already running?
I'm doing maintenance and don't want automation interfering?

If Claude just blindly runs and pushes code, it could:

Overwrite my work in progress
Race against CI/CD and cause conflicts
Stack multiple fix attempts on top of each other
Push broken code because it didn't have the full context

The Solution: Four Layers of Contention Prevention

I built a "do not disturb" system with four layers:

Layer 1: Lock File

LOCK_FILE="/tmp/boop-health-check.lock"

if [ -f "$LOCK_FILE" ]; then
    log "SKIP - Another health check is already running"
    exit 0
fi
touch "$LOCK_FILE"

Only one health check runs at a time. Period.

Layer 2: Uncommitted Changes Detection

if [ -n "$(git status --porcelain 2>/dev/null)" ]; then
    log "SKIP - Uncommitted changes detected in main repo"
    exit 0
fi

If I'm working on something, Claude backs off. My uncommitted changes are a signal that a human is actively developing.

Layer 3: CI/CD Awareness

RUNNING_ACTIONS=$(gh run list --repo "$GITHUB_REPO" --status in_progress --json databaseId --jq 'length')

if [ "$RUNNING_ACTIONS" != "0" ]; then
    log "SKIP - $RUNNING_ACTIONS GitHub Action(s) in progress"
    exit 0
fi

If GitHub Actions is deploying, Claude waits. No racing against the pipeline.

Layer 4: Manual Override

if [ -f "$MAIN_REPO/.no-health-check" ]; then
    log "SKIP - Do not disturb file present"
    exit 0
fi

If I'm doing something unusual and want automation to stay away, I create a .no-health-check file. Simple human override.

The Flow

Every 30 minutes:
┌─────────────────────────────────────────┐
│ Health Check Script Starts              │
└────────────────┬────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────┐
│ Check: Lock file exists?                │──Yes──▶ EXIT (another check running)
└────────────────┬────────────────────────┘
                 │ No
                 ▼
┌─────────────────────────────────────────┐
│ Check: .no-health-check file exists?    │──Yes──▶ EXIT (manual override)
└────────────────┬────────────────────────┘
                 │ No
                 ▼
┌─────────────────────────────────────────┐
│ Check: Uncommitted changes in repo?     │──Yes──▶ EXIT (human working)
└────────────────┬────────────────────────┘
                 │ No
                 ▼
┌─────────────────────────────────────────┐
│ Check: GitHub Actions running?          │──Yes──▶ EXIT (CI/CD in progress)
└────────────────┬────────────────────────┘
                 │ No
                 ▼
┌─────────────────────────────────────────┐
│ Run pre-checks (machines, API, queue)   │
└────────────────┬────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────┐
│ Launch Claude with context              │
│ - Check status                          │
│ - Review logs                           │
│ - Diagnose issues                       │
│ - Fix if possible                       │
└────────────────┬────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────┐
│ If fixes made → Email notification      │
└─────────────────────────────────────────┘

Bounded Autonomy

Claude isn't running wild. It has explicit boundaries:

Can do:

Read files and logs
Run bash commands (fly status, curl, etc.)
Edit code files
Grep/search the codebase
Commit and push to git

Cannot do:

Delete files
Access cloud provider directly (only via fly CLI)
Make speculative improvements

The prompt explicitly says:

"Only make code changes if there's a clear issue that needs fixing. Do NOT make speculative improvements or refactors."

Notifications: Only When It Matters

I don't get emailed for every health check. Only when something actually happened:

if echo "$CLAUDE_OUTPUT" | grep -qiE "(fixed|restarted|deployed|resolved|corrected|pushed to git)"; then
    send_email "$EMAIL_SUBJECT" "$EMAIL_BODY"
fi

If everything is healthy, the log just says "All systems healthy" and I never hear about it.

If Claude fixed something, I get an email with:

What the pre-check found
What Claude did to fix it
Full output for review

Real Results

In the past month:

48 health checks per day (every 30 minutes)
~1,400 total checks run automatically
3 automated fixes pushed while I slept
0 false positives or unnecessary alerts
0 conflicts with my development work

The fixes were real issues:

A worker that crashed and needed restart
A connection pool that needed tuning
A queue backpressure threshold that needed adjustment

Each time, I woke up to an email explaining what happened and what was fixed. Reviewed the changes, confirmed they were correct, moved on with my day.

Most importantly: I sleep well. I don't lie awake wondering if something's broken. I don't compulsively check my phone at 2am. I know that if something goes wrong, Claude will fix it and that lets me actually rest.

Why This Works for Solo Developers

If you're running infrastructure solo, you can't be on-call 24/7. You have to sleep. You have other things to do.

This approach gives me:

Coverage - Something is watching even when I'm not
Intelligence - Not just alerts, but diagnosis and fixes
Safety - Multiple layers prevent automation from causing problems
Transparency - I know exactly what happened and why

The contention strategy is the key. Without it, I'd be afraid to let automation touch anything. With it, I know Claude will back off whenever there's a reason to.

Try It Yourself

This pattern works with any infrastructure:

Write a health check script that does your pre-flight checks
Add contention prevention (lock file, git status, CI check)
Call Claude with bounded permissions
Only notify on actual fixes

The Claude CLI makes this straightforward. The --allowedTools flag lets you restrict what Claude can do, and --permission-mode bypassPermissions lets it run unattended.

Running a service solo? I'd love to hear how you handle on-call. Drop a comment below.

6 Free Developer Tools You Can Use Right Now (No Signup Required)

boop dev — Thu, 15 Jan 2026 15:52:53 +0000

6 Free Developer Tools You Can Use Right Now (No Signup Required)

Sometimes you just need a quick tool to check something. Is my SSL certificate expiring? What DNS records does this domain have? Is that port open?

I built these tools for Boop because I kept needing them myself. They are completely free, no signup required, and work right in your browser.

1. SSL Certificate Checker

URL: boop.one/tools/ssl-checker

Check any domain's SSL certificate instantly:

Certificate expiration date
Certificate chain validation
Issuer information
Days until expiry

Use case: Quick check before your cert expires and Chrome starts showing scary warnings to your users.

2. DNS Lookup

URL: boop.one/tools/dns-lookup

Query DNS records for any domain:

A, AAAA, CNAME, MX, TXT, NS records
Multiple record type support
Raw DNS response data

Use case: Debugging DNS propagation, checking MX records before setting up email, verifying TXT records for domain verification.

3. HTTP Headers Checker

URL: boop.one/tools/http-headers

See exactly what headers a URL returns:

Response status code
All response headers
Security headers check
Cache control settings

Use case: Debugging CORS issues, checking security headers, verifying cache settings.

4. WHOIS Lookup

URL: boop.one/tools/whois-lookup

Get domain registration information:

Registrar details
Registration and expiry dates
Nameserver information
Domain status

Use case: Checking when a domain expires, finding out who owns a domain, verifying domain transfers.

5. Ping Tool

URL: boop.one/tools/ping

Test if a host is reachable:

Response time measurement
Packet loss detection
Multiple ping support

Use case: Quick connectivity check, latency testing, verifying a server is up.

6. Port Checker

URL: boop.one/tools/port-checker

Check if specific ports are open:

TCP port scanning
Common port presets
Custom port input

Use case: Verifying firewall rules, checking if services are exposed, debugging connection issues.

Why Free?

Honestly? These tools bring people to Boop. Some of them end up signing up for monitoring (which is what we actually sell). But even if you never sign up, these tools are genuinely useful and I wanted them to exist.

Need Ongoing Monitoring?

If you find yourself checking these things repeatedly, you might want automated monitoring instead. Boop monitors your sites every 30 seconds from 4 global regions and alerts you when something goes wrong.

Free tier includes 10 monitors. No credit card required.

What other tools would be useful? Drop a comment - I might build it.

Monitor Your Side Project in 5 Minutes

boop dev — Thu, 15 Jan 2026 15:14:33 +0000

Monitor Your Side Project in 5 Minutes

Your side project is finally live. You shipped it. You're proud of it. But here's an uncomfortable question: how will you know when it goes down?

The answer, unfortunately, is usually "when an angry user tweets at me" or "when I notice it 3 days later." I've been there. It sucks.

I built Boop specifically because I got tired of finding out my projects were down from someone else. Now I'm going to show you how to set up monitoring in literally 5 minutes.

Why Bother Monitoring a Side Project?

Look, I get it. It's a side project. You're not running AWS here. But consider:

Users won't tell you - Most will just leave and never come back
Search engines notice - Downtime can tank your SEO
SSL certificates expire - And you'll forget until Chrome shows that scary warning
It takes 5 minutes - And Boop has a free tier, so there's zero excuse

The 5-Minute Setup

Step 1: Sign Up (30 seconds)

Head to boop.one and create an account. No credit card required for the free tier.

Step 2: Add Your First Monitor (1 minute)

Click "Add Monitor" and enter your URL. That's it. Boop will automatically:

Check if your site is up every 30 seconds
Monitor from 4 global regions (US East, US West, Europe, Asia)
Track response times
Check your SSL certificate expiration

Step 3: Set Up Alerts (2 minutes)

This is the important part. Go to Settings and connect your preferred notification channel:

Email - Classic, always works
Slack - Great if you live in Slack
Discord - Perfect for indie hackers
Webhooks - For the automation nerds

I personally use Discord because I have a private server for all my project notifications.

Step 4: (Optional) Create a Status Page (1 minute)

Want to look professional? Create a public status page for your users. It takes one click and you get a URL like status.yourproject.com that shows real-time uptime.

What You Get

With just those 5 minutes, you now have:

30-second checks from 4 continents
Instant alerts when something breaks
SSL expiry warnings before they become emergencies
Response time tracking to catch slowdowns
A status page to show users (and yourself) that you're serious

The Peace of Mind Factor

Here's what I didn't expect: the mental relief.

Before I had monitoring, there was always this low-grade anxiety. "Is my project up? Should I check? When was the last time I checked?"

Now I just... don't think about it. If something's wrong, I'll know within 30 seconds. If I don't get an alert, everything's fine. It's genuinely freeing.

Wrap Up

Look, monitoring isn't sexy. It's not a feature you can show off. But 5 minutes now saves you from:

Embarrassing "is it just me or is the site down?" messages
Lost users who silently bounced
The panic of discovering a 12-hour outage
Expired SSL certificates

Set up monitoring for your side project - your future self will thank you.

I'm building Boop as an indie hacker. If you have feedback or feature requests, I'd love to hear them in the comments or on Twitter.