Instatus alternative for monitoring and status pages in one bill
Logdash treats the public page as a view of monitors you are already running, so the checks, the alerts and the page are one subscription rather than a status page with monitoring bolted on beside it.
Most people arrive at Instatus for the page. Something broke, support got flooded, and you wanted one URL to point customers at. The page is genuinely good. It loads fast, subscribers work, and incident templates save you writing the same sentence twice at 3am.
Then you notice the page knows nothing on its own. Something has to decide the API is down. So you add Instatus monitors, and the status page you bought for one bad afternoon is now also your uptime tool, on a plan sized by monitor count and check frequency.
Logdash starts from the other end. You add HTTP monitors because you want to know when something breaks. The public page is a switch on the monitors you already have, on your own domain, in the same subscription. Alerts go to Telegram or a webhook, and those two are the entire list. No SMS, no phone calls, no on-call rotation.
Scope differs in both directions. Logdash carries logs and metrics from eight SDKs, so the failed request and the check that caught it sit in one dashboard. Instatus does not do logs. It does check things Logdash cannot: ping, TCP, UDP and DNS. Logdash stops at HTTP checks and push heartbeats for cron jobs.
The endpoint the monitor calls
from fastapi import FastAPI, Response
app = FastAPI()
@app.get("/health")
def health(response: Response):
if not database.reachable():
response.status_code = 503
return {"status": "down", "reason": "database"}
return {"status": "ok"}Instatus API alternative
Instatus has an API too, two in fact. Every page serves public JSON at /v3/summary.json and /v3/components.json, and the REST API at api.instatus.com manages pages, incidents and subscribers with a bearer token. So an API is not what you gain by moving. Logdash serves one public, read-only endpoint, /v1/status_pages/:id, with uptime per monitor from 1 hour to 90 days, 90 daily buckets and the last 100 checks. What ships on top is the difference: a typed client with React and Svelte bindings, a component you copy into your app with one shadcn command, and a Next.js starter. Instatus wins on writes, since its API can open an incident and Logdash has no incidents at all.
import { fetchStatusPage } from '@logdash/status';
const page = await fetchStatusPage('your-status-page-id');
console.log(page.status); // 'operational' | 'degraded' | 'outage' | 'unknown'
for (const monitor of page.monitors) {
console.log(monitor.name, monitor.status, monitor.uptime['30d']);
}- Add the monitor Paste the health URL. The first check runs straight away, then every 5 minutes on the free plan or every 15 seconds on Pro.
- Publish the page Turn the monitor on for a public status page and map your own domain. Uptime and response time come from the checks you are already paying for.
- Wire the alert Attach a Telegram channel, then return a 503 from the health endpoint on purpose. The alert arrives in the chat while you are still watching the tab.
Logdash vs Instatus
| Feature | Logdash | Instatus |
|---|---|---|
| What the product is built around | Monitors first, the page is a view of them | The page first, monitors added beside it |
| Logs and metrics | Same dashboard, eight SDKs | Not covered |
| Open source | AGPL-3.0, source on GitHub | Closed source |
| Custom domain on the page | Hosted page on your own domain, or your own build via API | Hosted page on your own domain, plus public JSON |
| Check types | HTTP and push heartbeats | Adds ping, TCP, UDP and DNS |
| Telling your customers | The page updates, nothing is sent | Email and SMS subscribers, on-call schedules |
| Writing the incident | No incident posts, the page shows the checks | Templates and scheduled maintenance |
When Instatus is the better pick
- The page is what your customers judge you on, and Instatus has spent years on exactly that page. Subscribers, templates and scheduled maintenance are all there and tested.
- You need to check something that is not HTTP. Ping, TCP, UDP and DNS monitors exist there and do not exist here.
- Your incident process involves an SMS or a phone call. Logdash sends Telegram messages and webhooks, nothing else.
What moving actually looks like
Recreate the monitors first and leave the Instatus page live. Run both for a week so you can compare what each one caught and how quickly. Then publish the Logdash page on a subdomain, and only redirect the customer-facing URL once you are happy. Give subscribers notice before you do, because the subscriber list does not come with you and the people who most need the page are the ones who will not read the announcement.