DEV Community: vaibhav

I Built an API Monitoring Platform Because My Own API Went Down and I Had No Idea

vaibhav — Tue, 23 Jun 2026 05:40:08 +0000

I Built an API Monitoring Platform Because My Own API Went Down and I Had No Idea

TL;DR: My deployed API went down silently. I found out hours later. UptimeRobot felt like overkill for a student project. So I built Monitorly — a real-time API monitoring platform with a live dashboard, email alerts (without spamming you), and uptime tracking. It's live and open source.

The Problem

I deployed my first production backend and felt great about it.

Then it went down. Silently. No alert, no notification, nothing. I found out hours later when I went to check it manually.

That's when I realised two things:

Every deployed project needs uptime monitoring
Existing tools like UptimeRobot felt like overkill — too many settings, too much noise, not built for someone just learning how production works

So I built my own. And in the process, I learned more about real-time systems, cron jobs, and backend architecture than any tutorial had taught me.

What is Monitorly?

Monitorly is a production-grade API uptime monitoring platform. You add your endpoints, it checks them on a schedule, shows you a live dashboard, and emails you when something goes down — without flooding your inbox.

Live: urlzap.me/pulsewatch
GitHub: github.com/vbv0507/api-monitoring-system

Features

1. Real-Time Dashboard with Socket.io

No page refresh needed. When a monitor check completes, the result pushes instantly to your dashboard via WebSocket. You see status changes the moment they happen.

2. Email Alerts — Without Spamming You

This was a deliberate product decision. Most monitoring tools email you on every failed check. If your API is flapping (going up and down repeatedly), you'd get 50 emails in an hour.

Monitorly only sends an alert when the status changes — down → alert sent. Back up → recovery email sent. One email per incident, not one per check.

3. Uptime Percentage Calculation

Every monitor tracks its full check history and calculates a rolling uptime percentage. You can see at a glance whether your API has been 99.9% up or quietly degraded over time.

4. Configurable Check Intervals

Checks run every 1, 5, or 15 minutes depending on how closely you need to watch an endpoint. The cron engine handles all of it automatically.

5. Per-User Monitor Isolation

Every user only sees their own monitors. JWT authentication ensures complete isolation — you can't accidentally see or affect someone else's data.

Tech Stack

Layer	Technology
Runtime	Node.js
Framework	Express.js
Database	MongoDB + Mongoose
Real-time	Socket.io
Scheduling	node-cron
HTTP checks	Axios
Email alerts	Nodemailer
Auth	JWT
Deployment	Azure App Service

How It Works — The Core Architecture

The Monitoring Engine

The heart of Monitorly is the cron-based monitoring engine. When a user adds a monitor, it registers a cron job that fires at the configured interval.

const cron = require('node-cron');
const axios = require('axios');

function scheduleMonitor(monitor) {
  const intervals = {
    1:  '* * * * *',      // every 1 minute
    5:  '*/5 * * * *',    // every 5 minutes
    15: '*/15 * * * *'    // every 15 minutes
  };

  const expression = intervals[monitor.interval] || '*/5 * * * *';

  cron.schedule(expression, async () => {
    await runCheck(monitor);
  });
}

Running a Health Check

Each check measures response time, status code, and whether the endpoint is reachable at all.

async function runCheck(monitor) {
  const startTime = Date.now();
  let status = 'down';
  let responseTime = null;
  let statusCode = null;

  try {
    const response = await axios.get(monitor.url, { timeout: 10000 });
    responseTime = Date.now() - startTime;
    statusCode = response.status;
    status = statusCode >= 200 && statusCode < 400 ? 'up' : 'down';
  } catch (err) {
    responseTime = Date.now() - startTime;
    statusCode = err.response?.status || null;
  }

  // Save the log
  await MonitorLog.create({
    monitorId: monitor._id,
    status,
    responseTime,
    statusCode,
    checkedAt: new Date()
  });

  // Push real-time update to dashboard
  io.to(monitor.userId.toString()).emit('monitor-update', {
    monitorId: monitor._id,
    status,
    responseTime,
    statusCode
  });

  // Handle alert logic
  await handleAlerts(monitor, status);
}

The Alert Logic — No Spam

This is the part I'm most proud of. Instead of alerting on every failed check, Monitorly tracks the previous status and only triggers an email when the state changes.

async function handleAlerts(monitor, newStatus) {
  const previousStatus = monitor.lastStatus;

  // Only act on status change
  if (newStatus === previousStatus) return;

  // Update stored status
  await Monitor.findByIdAndUpdate(monitor._id, { lastStatus: newStatus });

  if (newStatus === 'down') {
    // Send downtime alert
    await sendEmail({
      to: monitor.userId.email,
      subject: `🔴 ${monitor.name} is down`,
      body: `Your endpoint ${monitor.url} is not responding. Detected at ${new Date().toISOString()}.`
    });
  }

  if (newStatus === 'up' && previousStatus === 'down') {
    // Send recovery alert
    await sendEmail({
      to: monitor.userId.email,
      subject: `🟢 ${monitor.name} is back up`,
      body: `Your endpoint ${monitor.url} has recovered. Downtime ended at ${new Date().toISOString()}.`
    });
  }
}

One status change = one email. That's it.

Uptime Percentage Calculation

async function getUptimePercentage(monitorId, days = 7) {
  const since = new Date();
  since.setDate(since.getDate() - days);

  const logs = await MonitorLog.find({
    monitorId,
    checkedAt: { $gte: since }
  });

  if (logs.length === 0) return null;

  const upCount = logs.filter(log => log.status === 'up').length;
  return ((upCount / logs.length) * 100).toFixed(2);
}

Simple, accurate, and runs off the existing log data with no extra storage.

Real-Time Dashboard with Socket.io

When the monitoring engine runs a check, it emits a monitor-update event to the user's socket room. On the frontend, the dashboard listens and updates the UI instantly.

// Server — emit to user's room
io.to(monitor.userId.toString()).emit('monitor-update', updatePayload);

// Client — listen and update UI
socket.on('monitor-update', (data) => {
  updateMonitorCard(data.monitorId, data.status, data.responseTime);
});

No polling. No page refresh. The dashboard just stays live.

MongoDB Schema Design

// Monitor — what the user wants to track
const monitorSchema = new mongoose.Schema({
  userId:      { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  name:        { type: String, required: true },
  url:         { type: String, required: true },
  interval:    { type: Number, enum: [1, 5, 15], default: 5 },
  lastStatus:  { type: String, enum: ['up', 'down', 'pending'], default: 'pending' },
  createdAt:   { type: Date, default: Date.now }
});

// Log — individual check result
const monitorLogSchema = new mongoose.Schema({
  monitorId:    { type: mongoose.Schema.Types.ObjectId, ref: 'Monitor', required: true },
  status:       { type: String, enum: ['up', 'down'], required: true },
  responseTime: { type: Number },
  statusCode:   { type: Number },
  checkedAt:    { type: Date, default: Date.now }
});

// Index for fast log queries per monitor
monitorLogSchema.index({ monitorId: 1, checkedAt: -1 });

Separating monitors from logs is important — logs grow fast, and you don't want a single document ballooning with embedded arrays.

What I Learned Building This

1. Socket.io rooms are perfect for multi-user real-time apps.
Instead of broadcasting every update to every connected client, I put each user in their own room (socket.join(userId)). Clean isolation with one line of code.

2. Cron jobs need restart handling.
When the server restarts, all scheduled cron jobs are gone. I reload all active monitors from MongoDB on server startup and reschedule them. Always think about what happens on restart.

3. Alert logic is a UX problem, not just a technical one.
The "no spam" decision came from thinking about what I'd actually want as a user. Technical correctness (alert on every failure) is not the same as a good user experience. Think about both.

4. Separate your logs from your main documents.
Early on I stored check results as an embedded array inside the Monitor document. It hit MongoDB's 16MB document limit faster than expected. Separate collections with indexes is the right pattern for time-series data.

5. Timeouts are not optional.
Without a timeout on Axios requests, a hanging endpoint would block the check indefinitely. Always set a timeout on outbound HTTP calls in a monitoring system.

What's Next

[ ] SMS alerts via Twilio
[ ] Response body validation (not just status codes)
[ ] Public status pages per user
[ ] Webhook support for Slack / Discord notifications
[ ] Multi-region checks

Try It

Live: urlzap.me/pulsewatch
GitHub: github.com/vbv0507/api-monitoring-system

Add your own endpoints and watch the dashboard update in real time. If something breaks, you'll know immediately — not hours later like I did.

Questions about any part of the build? Drop them in the comments.

Also built: URLzap — a free URL shortener with custom aliases, because Bit.ly paywalls them. And yes, the short links in this post are from my own shortener.

Tags: #node #javascript #webdev #showdev

I Built My Own URL Shortener Because Bit.ly Charges for Custom Aliases

vaibhav — Tue, 23 Jun 2026 05:31:58 +0000

I Built My Own URL Shortener Because Bit.ly Charges for Custom Aliases

TL;DR: Bit.ly puts custom short links behind a paywall. So I built URLzap — a production-ready URL shortener with custom aliases, expiry, QR codes, click analytics, and JWT auth. It's live, free to use, and fully open source.

The Problem

I was sharing links to my side projects — Monitorly, my portfolio, GitHub repos — and wanted clean, memorable short URLs like urlzap.me/pulsewatch instead of a random string of characters.

Bit.ly's answer? Pay for a premium plan.

I'm a B.Tech student. I'm not paying $35/month to shorten my own links. So I did what any developer would do — I spent a weekend building it myself.

What is URLzap?

URLzap is a full-featured URL shortener built with Node.js, Express.js, MongoDB, and Azure. It's not just a redirect service — it has features I actually use daily.

Live: urlzap.me
GitHub: github.com/vbv0507/url-shortener

Features

1. Custom Aliases

The whole reason I built this. Instead of urlzap.me/xK92mP, I can create urlzap.me/pulsewatch for my Monitorly project. Clean, memorable, and free.

2. Link Expiry

Set an expiry date on any link. After that date, the link auto-deactivates. Useful for time-limited campaign links or sharing temporary access.

3. QR Code Generation

Every short link automatically generates a QR code. Handy for sharing links in presentations, README files, or anywhere you want a scannable format.

4. Click Analytics Dashboard

A per-link dashboard showing total clicks over time. You can see which links are getting traffic and when. Simple but genuinely useful for tracking your own projects.

5. JWT Authentication

All endpoints are secured with JWT. Each user only sees and manages their own links — no leaking between accounts.

6. Rate Limiting + Input Validation

Backend-level rate limiting to prevent abuse, and full input validation on all endpoints. Not an afterthought — built in from the start.

Tech Stack

Layer	Technology
Runtime	Node.js
Framework	Express.js
Database	MongoDB + Mongoose
Auth	JWT (jsonwebtoken)
QR Codes	qrcode npm package
Deployment	Azure App Service
CI/CD	GitHub Actions

How It Works — The Core Flow

Shortening a URL

// POST /api/links
// Creates a short link with optional custom alias and expiry

router.post('/', authenticate, async (req, res) => {
  const { originalUrl, customAlias, expiresAt } = req.body;

  // Check if alias is already taken
  const existing = await Link.findOne({ shortCode: customAlias });
  if (existing) return res.status(409).json({ error: 'Alias already taken' });

  const shortCode = customAlias || generateRandomCode(6);

  const link = await Link.create({
    originalUrl,
    shortCode,
    userId: req.user.id,
    expiresAt: expiresAt || null,
    clicks: 0
  });

  res.json({ shortUrl: `https://urlzap.me/${shortCode}`, link });
});

Redirecting + Tracking Clicks

// GET /:shortCode
// Looks up the link, checks expiry, redirects, and logs the click

router.get('/:shortCode', async (req, res) => {
  const link = await Link.findOne({ shortCode: req.params.shortCode });

  if (!link) return res.status(404).send('Link not found');

  // Check expiry
  if (link.expiresAt && new Date() > link.expiresAt) {
    return res.status(410).send('This link has expired');
  }

  // Log click and redirect
  await Link.findByIdAndUpdate(link._id, { $inc: { clicks: 1 } });
  res.redirect(link.originalUrl);
});

QR Code Generation

// GET /api/links/:id/qr
// Returns a QR code as a PNG data URL

const QRCode = require('qrcode');

router.get('/:id/qr', authenticate, async (req, res) => {
  const link = await Link.findById(req.params.id);
  const qrDataUrl = await QRCode.toDataURL(`https://urlzap.me/${link.shortCode}`);
  res.json({ qr: qrDataUrl });
});

MongoDB Schema

const linkSchema = new mongoose.Schema({
  originalUrl:  { type: String, required: true },
  shortCode:    { type: String, required: true, unique: true },
  userId:       { type: mongoose.Schema.Types.ObjectId, ref: 'User' },
  clicks:       { type: Number, default: 0 },
  expiresAt:    { type: Date, default: null },
  createdAt:    { type: Date, default: Date.now }
});

// Index for fast lookups on every redirect
linkSchema.index({ shortCode: 1 });

The shortCode index is important — every redirect hits this lookup, so it needs to be fast even at scale.

Deployment on Azure

The app runs on Azure App Service (Central India region) with GitHub Actions CI/CD. Every push to main triggers an automatic deploy — no manual steps.

# .github/workflows/deploy.yml (simplified)
- name: Deploy to Azure Web App
  uses: azure/webapps-deploy@v2
  with:
    app-name: 'urlzap'
    publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
    package: .

This means I can push a fix and it's live in under 2 minutes.

What I Learned Building This

1. Indexes matter more than you think.
Before adding the shortCode index, redirects were doing a full collection scan. After adding it, lookup time dropped dramatically. Always index fields you query frequently.

2. Input validation is not optional.
I got lazy on validation early on and had to go back and add it everywhere. Build it in from day one — middleware-based validation keeps it clean.

3. Expiry logic is tricky at scale.
I handle expiry on every redirect request right now. At scale, a background cron job that deactivates expired links periodically is a better pattern.

4. Rate limiting saves you from yourself.
Without rate limiting, a single script could hammer your redirect endpoint and spike your Azure costs. Add it early.

What's Next

[ ] Custom domain support (bring your own domain)
[ ] Link groups / folders for organisation
[ ] API access with API keys (not just JWT)
[ ] Detailed analytics (referrer, country, device)

Try It / Use the Code

Live: urlzap.me
GitHub: github.com/vbv0507/url-shortener

If you're tired of paying for custom short links, fork it, self-host it, or just use URLzap directly.

Happy to answer questions about any part of the build in the comments.

Also building: Monitorly — an API uptime monitoring platform. Check it out if you want to monitor your own endpoints.

Tags: #node #javascript #webdev #showdev