UptimeChecker is tasty mix of few different technologies: it is primarily based on .NET, all written in C#. We have .NET services for master and workers, and we also use Microsoft MVC for Dashboard and whole web site, PostgreSQL for data, and all that deployed on mix of Windows and Linux instances. And if you read the post How UptimeChecker was born, you already know that UptimeChecker was firstly developed to monitor WebSocket services, and we decided to also use WebSockets to glue everything together.

Backend

Backend core consists of two main components: master service and bunch of workers that performs actual uptime checks.

Master is full blown .NET service, written in C#, and its task is to coordinate all the work and make sure all the data is securely written to the database. It's deployed to Microsoft Windows Server.

Master have interface that can be accessed from the Dashboard to perform AdHoc checks (when you are creating or editing the monitor, and you want to test it, or from landing page) and it sends data to workers to perform checks. When worker returns check results, master evaluates the data and decides if it is time to perform more checks for the monitor (if check result is negative, master will ask few more workers to confirm the result). If monitor is confirmed failed, master will notify you about that (using any of alerting methods you configured for that monitor).

Workers

Workers are also .NET services, simple and lightweight, so they can easily be deployed to any number of virtual or physical servers, and they are completely compatible with Mono: this means they can be easily deployed to Windows or Linux machines. Each worker is completely the same, they only differ by configuration (each one knows its own name and location), and each one know how to perform all supported checks (PING, HTTP/S, WebSockets). All checks are performed asynchronous, so each worker can perform multiple checks in parallel.

Workers communicates with master using WebSockets, so we have direct and fast communication and we don't have to use additional component for message queues. Each worker on startup opens WebSocket connection to the master and is responsible to keep this connection open and healthy; if connection fails worker will try to reconnect to the master.

Master, on the other hand, know for all configured workers and their locations, so in case any of them isn't online for predefined time period, it will try to restart them several times, and ultimately report error if worker fails to get back up and running.

Web

UptimeChecker web interface consists of landing page with the product description and pricing details, and client Dashboard where you can add or edit your monitors and alarm contacts, and manage your account. Both are Microsoft .NET MVC Web Applications, backed by PostreSQL. For database access we use NHibernate, both on web interface and master service. Web interface is hosted on Microsoft Windows Server and served my Microsoft IIS.

All transactions for your subscriptions are handled securely by FastSpring. They provide all service related to subscriptions & payments so we can be focused on our core services, while they are focused on theirs: security and ease of use for the users. This also mean we never access your sensitive payment data.