--- title: "Instatus alternative with monitoring | Logdash" description: "You bought a status page and ended up buying uptime monitoring too. Logdash starts from the monitors. Here is the trade, including where Instatus wins." url: https://logdash.io/alternatives/instatus --- # 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 main.py ```python 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. status.ts ```typescript 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']); } ``` 1. **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. 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 | 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. ### 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 AGPL-3.0 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. ### Is there an Instatus API alternative? GET https://api.logdash.io/v1/status\_pages/:id returns a published Logdash page as JSON, with no key. The API docs live at logdash.io/docs/status-pages. It is read-only, so incidents and subscribers stay an Instatus strength. ## Keep reading [All alternatives](https://logdash.io/alternatives): One page per tool, each with the setup, the comparison and the case for staying where you are. [Atlassian Statuspage alternative for teams who need the checks too](https://logdash.io/alternatives/atlassian-statuspage): Statuspage does no monitoring of its own, so you are paying for the page plus whatever tool feeds it, while Logdash runs the HTTP checks and publishes the page from the same monitors. [UptimeRobot alternative for founders stuck on the 5-minute free tier](https://logdash.io/alternatives/uptimerobot): Logdash checks HTTP endpoints every 5 minutes on the free plan and every 15 seconds on Pro, and puts the logs and metrics from the same app in the same dashboard, so upgrading buys you more than a shorter gap between pings. [Uptime Kuma alternative for people who do not want to run a server](https://logdash.io/alternatives/uptime-kuma): Logdash is the hosted version of what Kuma does for most people - HTTP checks, heartbeats, a status page and alerts - with no VPS, no container and no SQLite file to back up. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.