Uptime monitoring
PULSX
Uptime monitoring for developers and teams: 60-second checks, heartbeat monitoring, SSL expiry tracking, and alerts in the places you already are.
- Our product
- 2025
PULSX watches websites, APIs, and background jobs, and tells you the moment something stops behaving. It exists because the monitoring market is split between tools that cost more than the thing they are watching and tools so thin they miss the outage entirely.
The problem
The challenge
Most small teams find out about downtime the worst possible way: a customer tells them. The tooling to prevent that has existed for twenty years, but it tends to arrive with enterprise pricing, a seat model that punishes you for adding a colleague, and an onboarding flow that assumes a dedicated ops function.
The free alternatives usually check every five minutes and only understand HTTP. That leaves two blind spots that cause real damage: a cron job that silently stopped running weeks ago, and a TLS certificate that expires at 2am on a Sunday. Neither shows up as a failed page load until it is already a problem.
We wanted a monitor that covers all three failure modes, alerts through the channels a small team actually watches, and does not require a procurement conversation.
What we did
The approach
The decisions that shaped the build, and why each one was made.
60-second checks with retry verification
HTTP and HTTPS endpoints checked every minute, with a retry before anything is declared down. Fast enough to matter, disciplined enough not to cry wolf.
Heartbeats for the things that do not serve traffic
Cron jobs and background workers ping a URL when they finish. Miss the window plus the grace period and PULSX raises an incident. This is the failure nobody else catches.
SSL expiry tracking
Certificates are watched continuously and flagged well before expiry, which turns a weekend outage into a Tuesday afternoon task.
Alerts where the team already is
Email, Slack, Discord, webhooks, and mobile push. An alert that arrives somewhere nobody looks is not an alert.
Public status pages
Hosted status pages so customers can see service health themselves rather than filling the support inbox during an incident.
Incident management and on-call
Incidents, on-call scheduling, and audit logging on the Pro tier, so a growing team can put a rota behind the alerts.
A REST API and a documented health endpoint
Monitors can be created and queried programmatically, so infrastructure changes and monitoring changes can ship together.
What came out
The outcome
PULSX runs a free tier with ten monitors on five-minute checks, which is enough for a personal project or a small production site, and a Pro tier with fifty monitors per seat on 60-second checks, every alert channel, multiple status pages, incident management, on-call scheduling, audit logs, and API access.
Heartbeat monitoring has been the most quietly valuable feature. Several of the failures it has surfaced were jobs that had been dead for days without a single HTTP check noticing, because nothing about the website looked wrong.
Related
Services this used
If you need something similar, these are the pages to read next.
Next step
Build something
If PULSX looks like the shape of what you need, tell us about your project. We reply to every message.
Usually within one working day