How a 5-Person SaaS Startup Runs 24/7 Monitoring on $10/month

The team and assumptions

Picture a pre-Series-A B2B SaaS startup, "Startup C": three engineers, two on the business side, 80 paying customers, one production server and one staging server in AWS Tokyo.

At this stage, three problems show up over and over:

• You don't have enough humans to run a real 24/7 on-call rotation.
• Every production outage is one customer-churn event closer to the next.
• You depend on Stripe / Auth0 / SendGrid, but their outages tend to surface as user complaints rather than your own alerts.

Here's how Startup C uses Miterl to cover all three for under $10/month.

Three monitoring axes, minimal footprint

Axis 1: Your own HTTP endpoints

Production HTTPS endpoints — /, /api/health, /api/v1/auth/login — are monitored on a 1-minute interval. /api/health is implemented as an unauthenticated handler that returns 200 only after probing the database, Redis, and key external APIs internally — so a single ping covers the whole infrastructure.

Axis 2: Heartbeat-based cron / batch monitoring

The 3 AM billing batch, the 5-minute email-sending worker, and similar background jobs all push a heartbeat ping to Miterl after a successful run.

# crontab
0 3 * * * /app/bin/run_billing.sh && \
  curl -fsS -m 10 --retry 3 https://miterl.com/heartbeat/$BILLING_TOKEN

If the batch fails, the heartbeat never arrives, and Miterl's timeout (e.g. "must arrive within 1 hour") fires. You catch silent batch failures the same way you'd catch a website outage.

Axis 3: Third-party API status via keyword monitoring

Stripe, Auth0, and SendGrid status pages are watched as keyword monitors. Each provider's status page renders a known string ("All Systems Operational" or similar) when healthy — when that string disappears, you know before your customers do.

# Stripe keyword monitor config (illustrative)
URL: https://www.stripestatus.com/
keyword: "All Systems Operational"
match: "must_contain"
interval: 5min

You hear about the Stripe outage in Slack, not in support tickets.

Workspace-level production / staging separation

Production and staging live in separate Workspaces:

• Production Workspace: 5 people total, business folks have viewer-only, engineers have member, CTO is the only owner.
• Staging Workspace: 3 engineers as owners, business team has no access at all.

This keeps staging noise out of business inboxes, and lets engineers (not just the CTO) toggle staging monitors on/off when iterating.

Deploy-time auto-maintenance

The GitHub Actions deploy workflow wraps the deploy in a maintenance webhook:

# .github/workflows/deploy.yml (excerpt)
- name: Pause monitoring
  run: |
    curl -X POST https://miterl.com/api/v1/webhooks/maintenance/${{ secrets.MITERL_TOKEN }}/start \
      -d '{"duration_hours": 1, "name": "Deploy ${{ github.sha }}"}'

- name: Deploy
  run: ./scripts/deploy.sh

- name: Resume monitoring
  if: always()
  run: |
    curl -X POST https://miterl.com/api/v1/webhooks/maintenance/${{ secrets.MITERL_TOKEN }}/end

The if: always() clause is critical — if a deploy fails midway, the resume call still runs, avoiding a "monitoring is paused forever because the deploy errored" hole.

What 5-person on-call actually looks like

Off-hours alerts hit Slack #oncall plus the on-call engineer's phone via SMS. Miterl's per-monitor severity routing keeps SMS for Critical only — everything else stays in Slack until the next business day.

The unwritten rule that actually keeps this sustainable: "Critical = respond now; everything else waits until tomorrow." Make it explicit.

Why $10/month is enough at this stage

Startup C runs on Miterl's Free plan plus a few minor add-ons:

• HTTP monitors: 5
• Heartbeats: 3
• Keyword monitors (third-party status): 4
• 1-minute checks
• Slack + email notifications

When ARR grows enough that customer contracts demand a 99.9% SLA, they'll move to the Pro plan and start sharing SLA reports with customers.

Related reading

• Miterl Documentation — Heartbeat setup
• HMAC signature verification guide — webhook security
• Pricing — Free / Plus / Pro thresholds
• All use cases — playbooks for other industries