What it does
Logdash watches the thing you shipped and tells you when it stops working.
Paste a URL and checks start right away, with the status code and response time of every check kept.
When a monitor goes down or comes back, you get a Telegram message or a webhook.
The logs and metrics from the same service are already on the same page, as the evidence for what actually happened.
- Cron and worker heartbeats. A push monitor is a URL your job calls when it finishes. No call, no heartbeat, alert. A normal uptime check can never see that failure.
- Alerts go to Telegram and webhooks today. Slack, email and PagerDuty are not built yet.
Uptime badges for your README
Every monitor on a published status page gets a badge.
The numbers come straight from the status page, so a badge can't round an outage away.
| Style | What it shows | Options |
|---|
classic | Uptime over a period, sized to sit next to your other badges | period=24h, 7d, 30d or 90d |
status | The monitor's name and its live state | theme=light or dark |
card | Name, 90-day uptime and one bar per day | theme=light or dark |
Publish a status page, open README badges in its settings, pick a style and copy the snippet.
A monitor's own settings have the same picker under README badge.
[](https://logdash.io/d/<page-id>)
On plans with a custom domain, badges come from your own domain, like status.acme.com/badges/<key>.svg, without the Logdash mark.
Getting started
Cloud (recommended)
Go to logdash.io, paste the URL you want watched, and press enter.
You get a monitor and a live dashboard without creating an account, because the app opens an anonymous workspace for you and only asks you to sign in when you want to keep it.
Self-hosting
Everything that runs Logdash is in this repo under the AGPL-3.0 licence, and the whole stack comes up locally for development in a few commands (see below).
Production self-hosting is not there yet, and we would rather say that than sell you a docker compose up that falls over in a week.
There is no packaged deployment, no upgrade path between versions, and the boot path still constructs Stripe and Resend clients, so a real instance wants real keys or a patch.
Work on a supported self-host deployment is tracked in the self-hosting issue; tell us there or in Discord if you need it, because that is what moves it up the list.
To run it on your machine, see Developing locally and CONTRIBUTING.md.
Sending data
Eight SDKs, one API key per service.
The SDKs are convenience wrappers.
The wire protocol is three HTTP endpoints on https://api.logdash.io, and nothing stops you from calling them directly.
| Endpoint | What it does | Auth |
|---|
POST /logs | ship one log line | project-api-key header |
PUT /metrics | set or mutate a metric | project-api-key header |
POST /ping/<monitorId> | heartbeat a cron or worker | none, and no body |
curl -X POST "https://api.logdash.io/logs" \
-H "project-api-key: <your-api-key>" \
-H "Content-Type: application/json" \
-d '{"message": "Application started successfully", "level": "info",
"createdAt": "2026-09-04T09:12:33.000Z", "sequenceNumber": 0}'
The heartbeat endpoint is deliberately public and takes no body, so a cron job can be one line: curl -fsS -X POST https://api.logdash.io/ping/<monitorId>.
How it fits together
flowchart LR
app["Your app, with an SDK"] -- "logs, metrics" --> api
jobs["Your cron jobs"] -- heartbeats --> api
frontend["apps/frontend<br>dashboard and site"] --> api
statuspage["apps/status-page<br>custom domains"] --> api
api["apps/backend<br>API and pinger"] --> stores[("MongoDB, ClickHouse, Redis")]
api -- "HTTP checks" --> urls["Your URLs"]
api -- "up and down" --> alerts["Telegram, webhooks"]
| Path | What it is |
|---|
apps/frontend | SvelteKit app and marketing site, deployed on Cloudflare Workers |
apps/backend | NestJS API, with MongoDB, Redis and ClickHouse |
apps/status-page | Renderer for status pages served on customer custom domains |
packages/hyper-ui | Shared Svelte 5 component library and Tailwind theme |
packages/status | @logdash/status on npm: status page client, React and Svelte bindings |
templates/status-page-next | Next.js starter for a self-hosted status page, outside the pnpm workspace |
pnpm workspaces, apps/* and packages/*, pinned to pnpm 10.7.0 in the root package.json.
Developing locally
Prerequisites: Node 22 (there is an .nvmrc), pnpm 10.7.0 via corepack enable, and Docker for MongoDB, Redis and ClickHouse.
nvm use && pnpm install
cp apps/backend/.env.example apps/backend/.env && cp apps/frontend/.env.example apps/frontend/.env
docker compose -f docker-compose.dev.yml up -d --wait
pnpm --filter backend migrate-up && pnpm --filter backend migrate-clickhouse
Then run the two apps in separate terminals.
pnpm dev:backend # API on http://localhost:3000
pnpm dev:frontend # app on http://localhost:5173
The backend reads apps/backend/.env at import time and refuses to boot without OUR_ENV and a reachable Mongo, Redis and ClickHouse.
The example file ships working placeholders for all of them.
The frontend example points at the production API, so you can work on the UI without running a backend at all.
CONTRIBUTING.md has the full environment reference, the OAuth setup, the migration details and how to run the test suite.
Contributing
Pick something up:
Read CONTRIBUTING.md before you open a PR, and come say hello in Discord if you want to talk something through first.
Security
Please do not open a public issue for a vulnerability.
SECURITY.md has the disclosure process and where to send it.
License
AGPL-3.0. See LICENSE.
Copyright (c) 2025 The Logdash Authors.
You can run, change and self-host Logdash for anything, including commercial use.
If you run a modified version as a service for others, you have to publish your changes under the same licence.
packages/hyper-ui, packages/status and templates/status-page-next are MIT, see the LICENSE file in each.
The hosted product at logdash.io runs this code with billing wired up and plan limits enforced.
There is no ee/ directory, no dual licence and no feature in this repo that is gated behind a paid key.
