# How to Monitor Deno Deploy Uptime

> Deno Deploy is a globally distributed edge platform for running JavaScript and TypeScript, used to host APIs, full-stack apps (including Fresh), and serverless functions close to users with fast cold starts.

*Source: https://monitoristic.com/monitor/deno-deploy*

---

## Why Monitor Deno Deploy?

Edge platforms like Deno Deploy are built for reliability, but your code still fails in ways the platform won't warn you about: an uncaught exception on a hot path, a bad environment variable after a deploy, an exhausted request or CPU-time limit, or a failing upstream (a database or KV store) that turns every request into a 500. Deno Deploy's status page covers the platform, not your project. If your API or app backs something real, an external monitor is what tells you your endpoint stopped returning good responses.

## What to Monitor

- `your-project.deno.dev` — Your project's URL — catches uncaught exceptions, bad deploys, and 500s
- `your-project.deno.dev/api/health` — A health route that checks downstream dependencies like a database or KV store
- `yourcustomdomain.com` — Your custom domain, if configured — catches SSL and DNS/domain issues separately

## What You Should Actually Do

1. Monitor your .deno.dev URL for a real 200 response so uncaught exceptions and bad deploys (missing env vars, broken imports) are caught immediately
2. Add a health route that checks downstream dependencies (database, KV, upstream APIs) so 'app up, data down' is detected
3. After each deploy, let monitoring confirm the new version actually serves correct responses — a successful deploy is not a working app
4. Monitor any custom domain separately to catch SSL and DNS issues independent of the project itself
5. Track response times across regions — rising latency or timeouts often precede CPU-time-limit failures on the edge

## Deno Deploy's Official Status Page

Deno Deploy publishes real-time status at https://status.deno.com. Your own monitor complements it by catching connection-level issues, often before the status page updates.

## Takeaway

Deno Deploy gives you a fast, globally distributed runtime — but it can't catch the failures in your own code: a thrown exception, a missing env var, an exhausted limit, or a dead dependency. The platform status page will stay green while your endpoint returns 500s. An external monitor checking for a genuine, correct response is what closes that gap and alerts you in 60 seconds.

## Frequently Asked Questions

### Does Deno Deploy alert me when my project goes down?

No. Deno Deploy's status page reports platform-level incidents, but it won't notify you when your specific project returns 500s, throws on startup, or fails after a bad deploy. Catching your own downtime requires an external monitor.

### Why does my Deno Deploy app return 500s when the platform is up?

Usually it's your code or config: an uncaught exception, a renamed or missing environment variable, an exhausted request or CPU-time limit, or a failing downstream like a database or KV store. The edge is fine; your project isn't — and only a monitor on your URL catches it.

### What's the best thing to monitor on Deno Deploy?

Monitor your project URL for a real 200 response, and add a health route that exercises your dependencies. For APIs, check the response body or status code so a wrong-but-200 response is also caught. Monitor custom domains separately for SSL and DNS.

### How is this different from status.deno.com?

status.deno.com reports incidents affecting Deno Deploy as a platform. It says nothing about your individual project erroring, a bad deploy, or a failing dependency. Only a monitor pointed at your endpoint catches your own outages.