Uptime Monitoring

Free — GPL coresize Mplanned, not built

Generated from docs/plan/core/uptime-monitoring/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need to know when their site is down so they can respond quickly. This feature provides uptime tracking from an external vantage point and downtime alerting.

The problem

My customers contact me to say the site is down, but I don’t know it myself. I need an external monitor that checks my site regularly and tells me immediately when it stops responding.

What it does

• Poll merchant’s storefront homepage (GET /) every 5 minutes from external monitoring service (e.g., simple HTTP checks)
• Record uptime_events collection: {timestamp, status_code, response_time_ms, status (up|down)}
• Calculate availability % (99.9%, etc.) over rolling 24h, 7d, 30d windows
• Display uptime dashboard in admin with: current status, availability %, downtime incidents log
• Log downtime incidents with: duration, start time, end time, status code that triggered
• Alert (email + webhook) when site transitions from up to down, and from down to up
• Show uptime trend graph (status dips in last 30 days)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Global monitoring from multiple regions (e.g., EU + US edge servers) — requires distributed monitoring infra, cost; defer to third-party service integration (Datadog, New Relic) or plugin
• Deep health checks (e.g., database connectivity, payment gateway status) — this is app-specific; core only checks HTTP GET /
• Historical uptime SLA reporting for contracts — that is billing/reporting, separate feature

Data model

uptime_events collection: {id, timestamp, status_code, response_time_ms, status}. downtime_incidents collection: {id, start_time, end_time, duration_minutes, trigger_status_code}. No migration; new collections.

API

• GET /api/admin/monitoring/uptime — fetch current uptime status and incidents
• GET /api/admin/monitoring/uptime/incidents?days=30 — list downtime incidents
• GET /api/admin/monitoring/uptime/history?days=7 — fetch detailed uptime timeline
• POST /api/admin/monitoring/uptime/alert-settings — configure alert email/webhook

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Admin panel shows ‘Uptime’ section. Status card displays: (1) current status (green ‘Up’ / red ‘Down’), (2) availability % for 24h/7d/30d, (3) incidents table (start, duration, end, trigger status), (4) 30-day uptime trend graph (green/red segments).

The seam — why this is core

Core owns uptime UI and event logging. Uptime checks run on a cron job or external endpoint (e.g., merchant can optionally use a free service like UptimeRobot, or core provides basic HTTP poller). No paid seam — core provides the infrastructure interface.

Core owns the interface + honest uptime checker; monitoring is infrastructure, not a support commitment or credential.

Dependencies

• Existing admin dashboard
• scheduler (to run uptime checks every 5 minutes)
• email layer (for alerting)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Stop the app and confirm uptime_events captures 5xx status codes within 5 minutes
• Restart app and confirm status transitions to ‘up’ and new incident logged
• Verify availability % calculation: 1 hour down in 24h = 95.83%
• Confirm downtime incident duration_minutes matches end_time - start_time
• Verify alert email is sent when status changes from up to down

Risks

If monitoring service fails, merchants lose visibility of actual downtime. Implement redundant checks (multiple monitors) or use third-party service with SLA. Storing uptime_events at 5-minute intervals = 288/day samples; 30 days = 8,640 rows — acceptable but implement retention policy.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.