Prompt of the Day: Set Up Uptime Monitoring for Your App
Part 27 of 30 in the Prompt of the Day series
Your app can go down at 2 a.m. on a Tuesday, and the first person to notice might be a frustrated user posting on social media. Uptime monitoring gives you a health check endpoint your app pings on a schedule, so you know about an outage before anyone else does. Getting this wired up correctly -- with both shallow and deep checks, alert routing, and a public status page -- is exactly the kind of infrastructure task where a well-crafted AI prompt saves you an hour of reading docs.
The Prompt
I need to set up uptime monitoring for a [Node.js / Python / Rails -- specify your stack] web application with a PostgreSQL database.
Please do the following:
1. Create a /api/health endpoint with two check levels:
- Shallow check: returns 200 if the server process is alive
- Deep check: verifies the database connection returns a successful query (e.g., SELECT 1)
- Return a JSON body: { "status": "ok" | "degraded" | "down", "db": "ok" | "error", "latency_ms": <number> }
2. Add integration with Better Stack (betterstack.com) as the primary monitoring service:
- Configure it to hit /api/health every 1 minute
- Set a 10-second timeout threshold
- Alert on 2 consecutive failures (not just one, to avoid false positives)
- Alert channels: Slack webhook at [YOUR_SLACK_WEBHOOK_URL], plus email to [YOUR_EMAIL]
3. As an alternative path, show me the equivalent UptimeRobot configuration (API or UI steps) targeting the same endpoint and alert thresholds.
4. Set up a public status page on Better Stack that displays the health monitor and any active incidents. Show me how to customize the page title and subdomain.
5. Define an alert escalation policy: first alert goes to Slack, then if unacknowledged after 10 minutes, send an SMS to [YOUR_PHONE_NUMBER].
Use environment variables for all credentials and webhook URLs. Add comments explaining the difference between a shallow check (is the process up?) and a deep check (can it reach downstream dependencies?).
Why It Works
This prompt works because it layers specificity at every decision point. Most developers know they need uptime monitoring; they just do not know what shape to ask for.
Concrete response shape. Specifying the exact JSON body (status, db, latency_ms) forces the AI to generate code you can actually test and parse, rather than a vague "return 200 if healthy" stub.
Named tools with explicit thresholds. Asking for Better Stack by name -- rather than "some monitoring service" -- means the AI can pull correct API field names, not invented ones. Specifying 2 consecutive failures prevents the alert spam that comes from single-failure triggers, which Better Stack's own documentation flags as a common misconfiguration.
Shallow vs. deep check distinction. This is the key architectural concept. A shallow check tells you the server process is alive. A deep check tells you whether the database connection pool is healthy, your cache layer is reachable, or a third-party API you depend on is responding. By naming both in the prompt, you get code that communicates real application health -- not just "the port is open."
Escalation path. Including the 10-minute unacknowledged escalation step matches how real on-call workflows operate, and the AI will generate the correct Better Stack escalation policy structure rather than leaving that as an exercise.
The Anti-Prompt
Add a health check to my app.
This fails for three reasons. First, it gives the AI no context about your stack, so you may get a health check written in the wrong language or framework. Second, "health check" with no further detail almost always produces a shallow check only -- a route that returns 200 regardless of database state, which is worse than no check at all because it gives you false confidence. Third, there is no mention of a monitoring service, so you get a health endpoint that nothing actually calls. You have built a smoke detector with no battery.
Variations
Better Stack with a cron heartbeat monitor
If you have a background job -- a nightly database backup, a report generator, a queue worker -- add this to your prompt:
Also create a heartbeat monitor in Better Stack for my nightly backup cron job.
The job should POST to the Better Stack heartbeat URL at the end of a successful run.
Alert me if no ping is received within 25 hours.
Better Stack calls these "heartbeat monitors," and they are the right tool for jobs where you need to know the task ran, not just that a server is alive.
UptimeRobot free-tier configuration
UptimeRobot's free plan covers 50 monitors on 5-minute check intervals, which is sufficient for most indie projects and early-stage apps. To scope the prompt to UptimeRobot only:
Configure UptimeRobot (free tier) to monitor /api/health.
Use their API to create the monitor programmatically, set keyword monitoring to assert the response body contains "status":"ok",
and configure email and Slack notifications.
The keyword assertion step is important: without it, UptimeRobot just checks for any 200 response, which means a degraded database state that returns 200 with "status":"degraded" would not trigger an alert.
DIY cron-based approach (no third-party service)
For internal tools or air-gapped environments:
Write a cron job that runs every 5 minutes, calls /api/health internally,
and sends a Slack webhook alert if the response is not 200 or if "status" is not "ok".
Log the result to a local file with timestamps. Use a dead-man's-switch pattern:
also alert if the cron job itself has not logged a result in 15 minutes.
This removes the external dependency at the cost of losing multi-region verification -- if your server is down, your cron job is also down, so you want that dead-man's-switch.
When You Would Actually Use This
You would reach for this prompt the moment you move from local development to a URL that real users can hit. According to a 2025 review of top uptime monitoring tools (https://resources.turbify.com/top-10-uptime-monitoring-tools-2025/), Better Stack now supports 30-second check intervals on paid plans and includes a usable free tier with 10 monitors and 3-minute checks -- enough to cover a small production app from day one. UptimeRobot remains the go-to for zero-budget setups, with 50 monitors free at 5-minute intervals.
The deeper reason to run this prompt early: health check endpoints are also used by load balancers, Kubernetes liveness probes, and deployment pipelines to decide whether traffic should route to a new instance. Building a proper deep-check endpoint now means you are not retrofitting it later under pressure.
Ask The Guild
What does your health check endpoint actually verify -- just the process, or do you include database, cache, and external API checks too? Drop your /api/health response shape in the thread. Bonus points if you have caught a real outage because of a deep check that a shallow check would have missed.