Pulse
ViewLightweight uptime monitoring, incident tracking, email alerts, and public status pages for critical services.
Keeping an eye on what matters
I built Pulse, an API and website monitoring platform that helps developers keep track of their services without constantly checking whether they're online.
Users can configure monitors with custom intervals, expected status codes, and request timeouts. Pulse handles the rest, running automated checks in the background, recording response times, and tracking availability over time.
A clearer picture of service health
A service being online doesn't always mean it's performing well. I wanted Pulse to make it easy to understand both availability and performance from one place.
Each monitoring check contributes to uptime calculations and response-time history. The details page brings this information together, showing how a service has performed over the last few hours, days, or weeks, alongside individual check results.

When something goes wrong
I built an incident-tracking system to capture outages and recoveries automatically. When a monitored service becomes unavailable, Pulse records the incident and tracks how long the disruption lasts.
Once the service recovers, the incident is resolved, preserving a history of what happened and when. I also integrated Resend to send email notifications for outages and recoveries, so users don't have to keep the dashboard open.

Behind the scenes
I built Pulse with Next.js, NestJS, PostgreSQL, Redis, and BullMQ. The API manages monitors and their configurations, while background workers handle recurring HTTP checks independently.
One interesting challenge was keeping scheduled jobs consistent when users changed their monitoring intervals. I implemented job cleanup and predictable identifiers to prevent outdated schedules from running duplicate checks.
I designed and developed the product end to end, from the monitoring workers and incident detection logic to the database architecture and frontend dashboard.
Pulse pushed me to think beyond building interfaces, particularly about background processing, scheduling reliability, and how to turn continuous streams of monitoring data into useful information.
