How to Set Up a Simple Uptime Monitor With Zero Dependencies

The monitoring industry has a complexity problem. Open any "how to set up monitoring" guide and you'll be told to install Prometheus, configure Grafana dashboards, set up Alertmanager, and maybe add a PagerDuty integration. By hour three, you're debugging your monitoring system instead of building your product.

But here's the thing: if you're running one API, a landing page, and maybe a database — you don't need any of that. You need to know two things:

1. Is my site up?
2. If it goes down, tell me immediately.

This guide shows you how to get exactly that, with zero dependencies installed on your server.

The Problem With Self-Hosted Monitoring

Before we get to the solution, let's understand why the "just run it yourself" approach fails for small projects:

• You need a separate server. If your monitoring runs on the same machine as your app, they go down together. Your monitor dies silently.
• Cron + curl is fragile. Network hiccups cause false alerts. No retry logic means alert fatigue. No history means you can't diagnose patterns.
• You maintain two systems now. Your monitoring stack needs updates, disk space, and its own uptime. That's double the operational burden for a solo developer.

The Zero-Dependency Approach

The simplest reliable monitoring setup has three properties:

1. Runs externally — on someone else's infrastructure, completely independent of yours.
2. Configurable via API — so you can add it to your deploy script and never think about it again.
3. Alerts via email — the one notification channel every developer already has configured.

Here's how to set this up in under two minutes.

curl -X POST https://watch.arkforge.fr/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

# Watch your API health endpoint every hour
curl -X POST https://watch.arkforge.fr/api/v1/watches \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yourapp.com/api/health",
    "interval_hours": 1,
    "notify_email": "you@example.com"
  }'

#!/bin/bash
# deploy.sh

echo "Deploying..."
git pull origin main
docker compose up -d

echo "Verifying deployment..."
sleep 5

# Trigger an immediate check after deploy
curl -s -X POST \
  https://watch.arkforge.fr/api/v1/watches/$WATCH_ID/check \
  -H "Authorization: Bearer $ARKWATCH_KEY"

echo "Deploy complete. Monitoring active."

What You Get (Without Installing Anything)

• External monitoring — Checks run from ArkWatch's servers. If your entire infrastructure goes down, you still get alerted.
• Email alerts — Immediate notification when a check fails. No Slack to configure, no webhook to set up.
• Change detection — Not just "is it up?" but "has the content changed?" Catches subtle failures like an app returning an error page with a 200 status.
• AI-powered summaries — When content changes, ArkWatch tells you what changed in plain English. No more diff-reading.
• History via API — Query past checks programmatically. Debug "when did this start failing?" without log diving.

Monitoring Patterns for Common Setups

REST API with a health endpoint

# Check every hour, alert on non-200
{
  "url": "https://api.yourapp.com/health",
  "interval_hours": 1
}

Static site or landing page

# Check every 6 hours, detect content changes
{
  "url": "https://yourapp.com",
  "interval_hours": 6
}

Webhook endpoint that must stay available

# Check every hour — critical for payment webhooks, etc.
{
  "url": "https://yourapp.com/webhooks/stripe",
  "interval_hours": 1
}

When You Need More

This approach covers 90% of solo developer and small team needs. But there are cases where you genuinely need more:

• Sub-minute checks — If you need to detect downtime within seconds, you need a dedicated monitoring stack.
• Complex assertions — If you need to validate JSON response schemas, check multiple endpoints in sequence, or test authentication flows.
• Multi-region checking — If you need to verify your app works from different geographic locations simultaneously.

For everything else — "is my side project still running?" — a simple API-based monitor is the right level of complexity.

Recap

1. Don't self-host monitoring for small projects. Use an external service.
2. API-first tools let you automate monitoring as part of your deploy process.
3. Email alerts are enough. You don't need Slack, PagerDuty, or OpsGenie for a side project.
4. Content checking catches failures that simple HTTP status checks miss.
5. Zero dependencies on your server means zero maintenance overhead.

Set it up once. Forget about it. Get woken up only when something actually breaks.

← Back to all articles