Most startups start monitoring the same way: a user emails in, something is broken, and the engineering team scrambles to find out when it started and why. After the third time this happens, someone says "we should set up monitoring."
This checklist gives you the complete picture—what to monitor, how to set thresholds, how to configure on-call rotations, when to use a status page, and how to build a monitoring strategy from scratch using Vigilmon. Work through it once, and you'll have a production-grade monitoring setup that most early-stage startups don't have until Series B.
Phase 1: Decide What to Monitor
Before you configure a single alert, list the things that need to be running for your product to work. These fall into two categories.
User-Facing Services
These are endpoints or pages that users interact with directly. If they break, users notice immediately.
Checklist:
- [ ] Your homepage or marketing site
- [ ] Login / authentication endpoint
- [ ] The primary product feature (the "one thing" your product does)
- [ ] Checkout or payment flow (if applicable)
- [ ] API endpoints your users or integrations call directly
- [ ] Mobile API gateway
Internal / Infrastructure Services
These don't face users directly, but when they fail, user-facing services break.
Checklist:
- [ ] Your background job processor health endpoint
- [ ] Database health check endpoint (exposed via your API layer)
- [ ] Cache service health (Redis, Memcached)
- [ ] Email delivery service (Sendgrid, Postmark, Mailgun health check URL)
- [ ] Third-party integrations your product depends on (Stripe, Twilio, payment gateways, etc.)
- [ ] CDN probe URL (verify your CDN is serving assets correctly)
- [ ] Webhook receiver endpoints (if you receive webhooks from third parties)
Rule of thumb: if a service going down would break something a user would notice within 10 minutes, monitor it.
Phase 2: Set the Right Thresholds
Setting a threshold too low creates alert fatigue. Setting it too high means you don't find out until the problem is bad. Here's how to calibrate.
Availability Thresholds
For critical services, alert immediately on any availability failure (returning non-2xx or timing out). For lower-priority services, you might alert only after consecutive failures (2–3 checks in a row) to avoid false positives from transient network blips.
Recommended check frequency:
- Critical services (auth, payment, primary feature): every 60 seconds
- High priority (secondary features, internal services): every 2–5 minutes
- Informational (third-party dependencies you can't control): every 5–10 minutes
Latency Thresholds
Start with your actual baseline. Measure P95 response time over the last 30 days and set your warning threshold at 2× baseline and your alert threshold at 4× baseline—or at whatever latency you know degrades UX meaningfully.
Common starting points by endpoint type:
- Authentication: warn at 500ms, alert at 1000ms
- Data fetch / search: warn at 800ms, alert at 2000ms
- Transactional (payment, submit): warn at 1000ms, alert at 2000ms
- Static content / CDN: warn at 200ms, alert at 500ms
Checklist:
- [ ] Measured P95 baseline for each critical endpoint
- [ ] Set warning threshold at roughly 2× baseline
- [ ] Set alert threshold at the latency that causes real UX degradation
- [ ] Configured availability alert after 1 failure (critical) or 2–3 consecutive failures (non-critical)
Phase 3: Configure Alert Routing
Who gets paged? When? For what? The most common monitoring failure mode isn't missing a threshold—it's alert fatigue from too many notifications going to too many people, resulting in everyone assuming someone else is handling it.
Alert Severity Tiers
Define three tiers before you configure anything:
P1 — Critical (wake someone up, any hour)
- Your product is down or a primary user flow is broken
- Page the on-call engineer immediately via PagerDuty, OpsGenie, or phone call
P2 — High (notify immediately, business hours escalation)
- Latency is severely degraded but the service is up
- A secondary feature is broken
- Alert via Slack with @here or a specific channel
P3 — Low (inform, no immediate action needed)
- Third-party services are degraded
- Non-critical internal services are slow
- Daily digest or low-priority Slack channel
On-Call Rotation Setup
Checklist:
- [ ] Defined who is on-call (individual or rotation schedule)
- [ ] Configured primary alert channel (Slack, PagerDuty, email)
- [ ] Set up escalation path if the primary on-call doesn't acknowledge within N minutes
- [ ] Tested the alert path end-to-end (trigger a test alert, confirm it arrives)
- [ ] Documented the on-call runbook: what to check first, who to escalate to, how to update the status page
Alert Routing Rules
In Vigilmon, connect each monitor to the right channel:
- Critical monitors → PagerDuty or phone-based alert
- High priority monitors → Slack #alerts or #on-call
- Low priority monitors → Slack #monitoring-digest or email
Checklist:
- [ ] Connected Slack workspace to Vigilmon
- [ ] Connected PagerDuty (or equivalent) for P1 alerts
- [ ] Configured email fallback for escalation
- [ ] Verified alert routing by checking a test trigger reaches the right channel
Phase 4: Set Up Your Status Page
A status page is not just a transparency tool—it's a support deflection tool. When something breaks and users can't access your product, they go looking for information. If there's no status page, they email support, post on social media, or churn silently. A status page channels that energy productively.
What to Include on Your Status Page
Checklist:
- [ ] List each major service component (Auth, API, Dashboard, Payments)
- [ ] Show real-time status (operational / degraded / outage) pulled from your monitor results
- [ ] Link the status page URL from your app's footer and login page
- [ ] Enable incident posts so you can communicate during active incidents
- [ ] Set up subscriber notifications (email or webhook) so users can opt into alerts
When to Post an Incident Update
Post an update within 15 minutes of detecting an incident. Even if you don't know the cause yet, "We are investigating an issue affecting the login endpoint. Engineers are engaged." is better than silence.
Follow up every 30 minutes until resolved. Post a resolution update with a brief root cause summary.
Incident update template:
[Time] Investigating — We are investigating reports of [issue]. Engineers are engaged. [Time] Identified — We have identified the cause as [brief description]. A fix is being deployed. [Time] Resolved — This incident has been resolved. [Service] is fully operational. We will publish a post-mortem within 48 hours.
Checklist:
- [ ] Published status page URL (share it in your app and on your website)
- [ ] Configured component list to match your actual services
- [ ] Tested incident posting flow
- [ ] Added status page link to support auto-reply emails
Phase 5: Build Your Monitoring Strategy
The checklist items above handle the mechanics. A monitoring strategy handles the decisions—when to add new monitors, how to manage alert fatigue, and how to keep your monitoring relevant as your product evolves.
Adding New Monitors
Trigger: any time engineering ships a new endpoint that a user depends on.
Checklist:
- [ ] New endpoints added to Vigilmon within 24 hours of deploy
- [ ] Threshold calibration done against observed baseline within the first week
Managing Alert Fatigue
If your on-call engineer is being paged more than 2–3 times per week for non-critical issues, your thresholds are too sensitive or your alert routing is too aggressive.
Checklist:
- [ ] Review alert history monthly—identify alerts that fired but required no action
- [ ] Raise thresholds or move noisy alerts to lower severity tiers
- [ ] Never silence an alert without a tracked reason—silencing is a symptom, not a fix
Monthly SLA Review
If you have uptime commitments to customers (even informal ones), review your Vigilmon uptime history monthly.
Checklist:
- [ ] Export monthly uptime report for each critical service
- [ ] Compare against any contractual or stated SLAs
- [ ] Flag any months where availability dipped below target
- [ ] Document root causes for any incidents that affected availability
Quarterly Monitoring Audit
Every quarter, do a 30-minute review of your monitoring setup:
- [ ] Are there services you've added since the last audit that aren't monitored?
- [ ] Are there monitors for services that no longer exist?
- [ ] Are threshold still appropriate given current usage patterns?
- [ ] Is the on-call rotation up to date with current team?
- [ ] Has the status page been tested recently?
The Vigilmon Quick-Start Path
- Sign up at vigilmon.online — free trial, no credit card required
- Add your 3 most critical endpoints — login, your primary feature, and payment if applicable
- Set response time thresholds — use 2× your observed baseline
- Connect Slack — get your first alert in under 5 minutes
- Publish your status page — share the URL with your team
- Add remaining services — work through Phase 1 of this checklist
- Configure PagerDuty — for P1 alerts that need to wake someone up
- Run a test incident — trigger a failure, confirm the page, practice the status page update flow
Conclusion
Uptime monitoring isn't a one-time setup task—it's an ongoing practice. The teams that do it well treat monitoring as part of shipping: every new feature comes with monitors, every incident produces a threshold review, and every quarter brings a deliberate look at whether the monitoring still reflects how the product actually works.
This checklist gives you the foundation. Vigilmon gives you the tools. The rest is building the habit.
Set up your monitoring in under 30 minutes →
Vigilmon is purpose-built uptime monitoring for startups and technical teams who need reliable, low-friction visibility into what their product is doing in production.