Pulsegram — Telegram-based uptime monitor
For developers running small services: Pulsegram watches a public URL and messages you on Telegram when it goes down, and again when it comes back.
How it works
- Add a URL. A health endpoint if you have one, your homepage if you don't. Set how often to check it.
- Connect Telegram. One button gives you a code; send it to the bot and the chat is linked.
- Get told when it breaks. One message when it goes down, one when it recovers. Nothing in between.
No card, no waitlist. Setup takes about ten minutes.
What Pulsegram can monitor
- Any publicly reachable
http://orhttps://URL on port 80, 443, 8080 or 8443. - Health endpoints that return 2xx, and ones behind auth that return 401 or 403 — a server answering is a server that is up.
- Bot webhooks, APIs, landing pages, admin panels, cron receivers.
- Several projects per account, each with its own interval and its own failure threshold.
What it cannot monitor
- Anything not reachable from the public internet — localhost, private ranges, VPN-only services, internal DNS names. These are blocked deliberately, not by oversight.
- Endpoints that need custom headers, a POST body, or an API key. Checks are plain GET requests.
- Ports other than 80, 443, 8080 and 8443.
- Anything below a 10-second interval. Faster is closer to a load test than to monitoring.
Why Telegram
Because the alert has to land somewhere you actually look. Email gets filtered into a folder you open on Mondays; a dashboard needs you to remember to open it. Telegram is already on your lock screen, it is free, and if you run bots your service already lives there. More channels may come later — this one covers the case that matters first.
Your data
Pulsegram stores your email, a hash of your password, the URLs you monitor,
and the results of those checks. Download everything as JSON from the
projects page, or delete the account and all of its history from the same
page. API clients can use GET /me/export and
DELETE /me with a bearer token. Logs record account ids
rather than email addresses
or Telegram chat ids, and are rotated on a fixed schedule. Nothing is shared
with third parties.
Monitoring Pulsegram
Pulsegram watches itself from the inside, but a process that dies cannot
report its own death. Point an external monitor at GET /health
from at least one machine that isn't this one — a check running on the same
server goes down with it.
200with"status":"ok"— API answering, database reachable, worker ticking.200with"status":"degraded"— running, but the worker has been silent; checks may be stalled.503with"status":"error"— the database is unreachable and the service cannot do its job.
Start monitoring — free API docs
Questions
Why did my URL get blocked?
Most likely it points somewhere that isn't reachable from the public
internet — localhost, a private range like
10.x or 192.168.x, a VPN address, or an internal
DNS name. Pulsegram fetches URLs on your behalf, so letting it reach
private addresses would turn it into a tool for probing networks it has no
business touching. The other common reason is a port outside 80, 443, 8080
and 8443. The error message in the form says which rule you hit.
Can I monitor localhost, a private IP, or a VPN service?
No, and this will not change. It is the same restriction that keeps Pulsegram from being used to scan other people's networks. If your service is internal, you would need a monitor that runs inside your network — Pulsegram runs outside it by design.
Why did I not receive an alert immediately?
Three things space it out. Your project is checked on its own interval, so a failure can wait up to that long to be noticed. Then it has to fail the configured number of times in a row before it counts as down. Then the message goes through a send queue that respects Telegram's rate limits. With a 60-second interval and a threshold of 2, expect roughly two to three minutes between the outage and the message.
What does the failure threshold mean?
How many checks in a row must fail before Pulsegram calls your project down. At 2 — the default — a single failed request is ignored, which is what you want: one flaky DNS lookup or one restart during a deploy should not wake you. At 1 you hear about everything immediately, including noise. Recovery works the same way in reverse: one successful check clears it.
Why do I need to connect Telegram?
Because that is the only place alerts go. Until a chat is linked there is nowhere to send them. Nothing is lost in the meantime — alerts raised before you connect are stored and delivered the moment you do.
What data do you store?
Your email, a bcrypt hash of your password, your Telegram chat id once you link it, the URLs and settings of your projects, and the result of each check: status, HTTP code, response time, and the error text if there was one. Page contents are not fetched or stored beyond that. Check history is kept for 30 days and alert history for 90.
How do I export or delete my data?
Sign in and use Download my data (JSON) on the projects
page — it returns your account, projects and history as one document.
Deleting works from the same page: it asks you to type your email, then
removes the account and everything attached to it, immediately and
permanently. API clients can call GET /me/export and
DELETE /me with a bearer token instead.
What happens if Telegram is unavailable?
The alert is recorded first and sent second, so an outage on Telegram's side does not lose the record. Messages wait in a queue and are retried with a growing delay, respecting the retry delay Telegram asks for, up to six attempts. An alert that never got queued is picked up by a background pass and queued again — but only while it is less than a day old, because a "your site is down" message from yesterday is noise rather than news. Once the attempts run out, or the alert is older than that, it stays marked as undelivered and is not sent. Delivery is not guaranteed.
Is Pulsegram free?
Yes, and there is no billing system to charge you with. This is early access: the goal right now is a handful of people using it seriously and telling me what breaks. If that changes, you will hear about it before it does, not after.
Can I monitor authenticated endpoints?
Only if they answer a plain GET without credentials. Pulsegram sends no headers, no body and no API key, so an endpoint returning 401 or 403 will be treated as up — the server answered. A health endpoint that requires a token cannot be checked properly yet.
How reliable is this?
Checks run from a single server in one region, so a network problem on my end can produce a false alarm, and there is no cross-checking from a second location. For a side project or an early-stage service that is a fair trade. If a missed outage costs you real money, run Pulsegram alongside something with more infrastructure, not instead of it.