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.
The rest of the difference is scope in both directions. Logdash also carries logs and metrics from eight SDKs, so the request that failed and the check that caught it sit in one dashboard. Instatus does not do logs. Going the other way, Instatus checks things Logdash cannot: ping, TCP, UDP and DNS. Logdash does HTTP status and response time plus push heartbeats for cron jobs, and that is where the list ends.
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"}Cron jobs work the other way round. Instead of Logdash calling you, the job calls Logdash: a POST to https://api.logdash.io/ping/<monitorId> when it finishes. The endpoint is public, takes no body and no auth header, so it is one curl at the end of a script. If the job stops running, the heartbeat stops arriving and the monitor goes down. Instatus has cron monitors too, so this is not a reason to move on its own. It is a reason you lose nothing if you do.
- 1 Add the monitor Paste the health URL and pick an interval. The first check runs straight away, so you find out in seconds if the endpoint does not answer from outside.
- 2 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.
- 3 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 | MIT, source on GitHub | Closed source |
| Custom domain on the page | Point your own domain at it | Point your own domain at it |
| 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 | Type the update on the page | 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.
Is there a free alternative to Instatus?
Logdash has a free Hobby plan that covers monitors, alerts and a public status page. Both products have limits on their free tiers, so read them before you move anything customer-facing.
Is there an open source alternative to Instatus?
Logdash is MIT licensed with the source on GitHub. If you want something you can deploy yourself today, Uptime Kuma and Cachet are the usual answers, because Logdash self-hosting is still development-only.
Does Logdash do ping, TCP or DNS checks like Instatus?
No. HTTP status and response time, plus push heartbeats for cron and background jobs. If you need to watch a port or a DNS record, Instatus does that and Logdash does not.
Can I keep my status page URL?
Yes, if it is on your own domain. Point it at the Logdash page when you are ready. Tell subscribers first, since the subscriber list itself does not transfer.