Pre-Launch Monitoring Checklist for Web Agencies

"Site Went Live, Then Immediately Went Down"

Launch day should feel like a milestone, not a crisis. But "the site was down five minutes after launch" or "the SSL certificate showed a browser warning on day one" are more common than they should be — and almost entirely preventable with the right monitoring setup in place before you flip the switch.

This checklist covers the eight monitoring items every web agency should configure before a client site goes live. Add it directly to your project completion workflow so nothing gets skipped in the excitement of launch day.

Pre-Launch Monitoring Checklist

✅ 1. HTTP Uptime Monitor

First priority. Register the URL and start checking availability at 1-3 minute intervals before the domain goes live. If a misconfigured server or caching issue takes the site down in the first hour, you will know immediately rather than hearing about it from the client.

# Create an HTTP monitor via the Miterl API
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client A - Production",
    "url": "https://client-site.example.com",
    "type": "http",
    "interval_seconds": 180,
    "alert_contact_ids": [1, 2]
  }'

alert_contact_ids are the IDs of your configured alert contacts. Retrieve them with GET /api/v1/alert-contacts.

• HTTP monitor created (1-3 minute check interval)
• Alert contacts (Slack, email, etc.) configured and attached
• Test alert sent and confirmed received

✅ 2. SSL Certificate Monitor

Enable SSL monitoring the moment the domain is live. Even with Let's Encrypt and auto-renewal configured, failures happen after server migrations or DNS changes. A 30-day-before alert gives you plenty of time to respond without urgency.

# Create an SSL certificate monitor
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client A - SSL",
    "url": "https://client-site.example.com",
    "type": "ssl",
    "interval_seconds": 86400,
    "ssl_expiry_alert_days": 30
  }'

• SSL monitor created (ssl_expiry_alert_days: 30)
• Certificate is valid — padlock appears in browser address bar
• HTTP-to-HTTPS redirect confirmed working correctly

For the full SSL monitoring workflow, see "How to Prevent SSL Certificate Expiry Disasters."

✅ 3. DNS Monitor

Essential if your agency manages the client's domain. DNS monitors catch unintended record changes and misconfiguration after nameserver migrations before they affect users.

# Create a DNS monitor
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client A - DNS",
    "url": "client-site.example.com",
    "type": "dns",
    "interval_seconds": 3600,
    "alert_contact_ids": [1]
  }'

• DNS monitor created (1-hour check interval)
• A record and CNAME point to the correct IP address
• DNS propagation complete — verified across multiple regions (e.g., via whatsmydns.net)

✅ 4. TTL Optimization Around Launch

Launches often involve DNS changes. If TTL is set high when a misconfiguration happens, you are stuck waiting hours for the fix to propagate to users.

# Recommended TTL approach around launch
# 1 week before launch through launch day: reduce TTL to 300 seconds
A    client-site.example.com    300    IN    192.0.2.1

# 1-2 weeks after stable launch: return to standard TTL
A    client-site.example.com    3600   IN    192.0.2.1

• TTL reduced to 300 seconds at least 2-3 days before the DNS cut-over
• Plan in place to restore TTL to normal after the site is confirmed stable

✅ 5. Heartbeat Monitor for Scheduled Jobs

Heartbeat monitoring answers "did my cron job actually run?" — not just "is the server responding?" If SSL auto-renewal or a nightly backup silently stops running after launch, a heartbeat monitor catches it.

Configure the scheduled job to send a ping to Miterl after each successful execution. If the ping does not arrive within the expected window, an alert fires.

# Example: ping Miterl after a backup script runs (add to crontab)
0 3 * * * /path/to/backup.sh && \
  curl -s https://miterl.com/api/v1/monitors/YOUR_HEARTBEAT_MONITOR_ID/heartbeat \
    -H "Authorization: Bearer YOUR_API_KEY" > /dev/null

Create a heartbeat monitor from the dashboard by choosing type heartbeat when adding a new monitor. Set the expected interval to match your cron schedule.

• Heartbeat monitor created for SSL auto-renewal script
• Heartbeat monitor created for nightly backup job
• Expected interval and grace period set appropriately per job

✅ 6. Client-Facing Status Page

Publishing a status page on launch day eliminates the "is the site down or is it just me?" support request pattern. Clients self-serve instead of calling you, so your team stays focused on resolution when incidents do happen.

Standard plan and above support white-label configuration (custom domain, no "Powered by Miterl" attribution).

• Status page created and set to public
• Status page URL shared with the client
• Custom domain CNAME configured (status.clientdomain.com → cname.miterl.com) for Standard and above

For status page setup and operational best practices, see "How Status Pages Reduce Client Support Requests."

✅ 7. Alert Routing and On-Call Coverage

Post-launch incidents can happen overnight or on weekends. Before the site goes live, confirm who gets the alerts and who acts on them.

# Verify your configured alert contacts
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, name, type}'

• Slack channel has all relevant team members joined
• Email addresses are active and monitored regularly
• After-hours contact method (LINE, SMS) configured for high-priority sites
• On-call rotation or escalation path documented and communicated

✅ 8. Sitemap Submission to Search Engines

Not a monitoring item strictly, but a launch-critical SEO step that belongs in the same checklist. Submitting the sitemap right at launch gives search engines a direct path to crawl new content.

• sitemap.xml is accessible and correctly formatted
• Sitemap submitted to Google Search Console
• Sitemap submitted to Bing Webmaster Tools
• robots.txt reviewed — no important pages accidentally blocked

Post-Launch Verification Window (First 24 Hours)

Even with all eight items checked, plan for active monitoring during the first 24 hours.

1. First hour: Confirm all monitors show "UP" in the dashboard
2. First 8 hours: Watch for response time spikes or HTTP error codes
3. First 24 hours: Confirm no overnight alerts fired and heartbeat pings arrived on schedule

If an incident does occur, follow the "Incident Response Playbook" to move from detection to resolution and post-mortem efficiently.

Summary

Pre-launch monitoring setup is one of those tasks that feels optional until the moment it is not. Running through this checklist before every launch protects client trust at the most fragile moment in the project lifecycle — and gives your agency a repeatable, professional process that scales with your client roster.

• HTTP, SSL, and DNS monitors go live the same moment the site does
• Reduce TTL before any DNS change and restore it after confirming stability
• Use heartbeat monitors to verify scheduled jobs are actually executing
• Publish a status page so clients can self-serve during incidents

For detailed setup instructions, see the documentation. Try the full setup yourself by signing up for free. For the complete monitoring-as-a-maintenance-service picture, see the use cases for web agencies.