Inspiration
PulseCheck was inspired by the need for simple, reliable service monitoring. As a backend engineer, I`ve seen how unnoticed downtime or slow endpoints can silently cause issues across systems. I also wanted to challenge myself to build a continuously running background service that deals with real-world concerns like background processing and reliability.
What it does
The system consists of two main components: an API service and a background worker.
The API service allows users to register GET endpoints they want to monitor, along with a failure threshold for each endpoint. The background worker, which shares a database with the API service, periodically retrieves the registered endpoints, sends HTTP requests to them, and logs health-check details such as status (Success or Failure) and latency.
If an endpoint fails consecutively a number of times equal to or greater than its configured threshold, the system automatically marks the endpoint as down.
How we built it
PulseCheck was built as a modular backend system using .NET and PostgreSQL. The project is split mainly into a Web API for endpoint registration and querying, and a background worker responsible for continuously monitoring registered endpoints.
It also consists of a shared Core layer that defines domain models, enums and interfaces, as well as an Infrastructure layer that handles data persistence using EF Core and external HTTP communication. The background worker runs on a timed schedule, retrieves registered endpoints, performs health checks, records latency and status, and updates endpoint status based on configurable failure thresholds.
This separation allows the system to remain maintainable, testable, scalable, and close to real-world backend service architecture.
Challenges we ran into
One of the main challenges was handling long-running background processes alongside database operations. Ensuring that database contexts were used safely in a continuously running worker required careful attention to dependency lifetimes and execution flow.
Another challenge was designing the system to remain simple while still reflecting real-world concerns like reliability, failure thresholds, and continuous monitoring. Balancing correctness, clarity, and scope within the hackathon timeframe was a constant consideration.
These challenges pushed us to better understand background processing, concurrency, and service boundaries in backend systems.
Accomplishments that we're proud of
Some of the accomplishments we are most proud of include:
- Designing and implementing a continuously running background worker
- Successfully separating concerns using Core, Infrastructure, API, and Worker layers
- Implementing configurable failure thresholds and endpoint state transitions
- Building a reliable system using minimal dependencies
- Debugging and resolving real concurrency and lifecycle issues under time pressure
What we learned
In the words of Albert Einstein, "Once you stop learning, you start dying". In that spirit, here are a few things we learned:
- How background workers behave differently from request-based APIs
- The importance of proper dependency lifetimes in long-running services
- Practical trade-offs in system design during constrained timelines
- How small architectural decisions can have large operational impact
What's next for PulseCheck
PulseCheck was designed as a backend-first system, with reliability and simplicity as the priorities. In future iterations, we see natural extensions to enhance its usability and observability:
- Multi-organization support: Adding authentication and authorization to allow teams to manage their own endpoints securely.
- Metrics and trends: Exposing historical health check data to enable analytics and visualizations.
- Alerting mechanisms: Integrating notifications for downtime or threshold breaches, such as via email or Slack.
- Scalability enhancements: Optimizing scheduling and parallel health checks for larger endpoint sets.
These improvements reflect how PulseCheck could evolve, while keeping the core system robust and reliable.
Log in or sign up for Devpost to join the conversation.