Monitor Your Django Site with UptimeRobot

Set up fast uptime checks and downtime alerts for a deployed Django app

Django UptimeRobot tutorial

What is Uptime?

From Wikipedia:

Uptime is a measure of system reliability, expressed as the period of time a machine, typically a computer, has been continuously working and available. Uptime is the opposite of downtime.

In simple terms, uptime measures how long your website is running without downtime. If your website goes down for 10 minutes in a day for whatever reason (system updates, server errors, etc), then your site is working for 1,430 minutes a day — or for 99.31%. This percentage is your uptime measure.

This translates to 300 minutes of downtime in a month, or 3650 minutes of downtime in a year. The optimal measure of course depends on the nature of your application: 300 minutes of downtime in a medium-sized web log is a minor inconvenience but possibly a huge amount of lost revenue for an e-commerce site.

Uptime is closely tied to the concept of High Availability (HA). This is where the nines come into play. As of now, the highest nines are 12 nines: this means the site is down only for 31.56 microseconds in a year! This is the gold standard of uptime that is achieved only by the biggest websites, like Google, Amazon, and Instagram.

High Availability Table

In a production environment, everything that can go wrong will go wrong. There are a million things that can go wrong: database updates, broken code, server upsize, etc. Therefore, the uptime measure is not a silver bullet for how well your site is working. It does not measure performance, usability, usefulness of a web application. It just measures the uptime status of your application over a period of time.

What is UptimeRobot?

So, how do we measure the uptime status of our application? Usually, by depending on the external service that checks for the status of our site. This type of service works by sending periodic requests, usually in every 30 seconds to 5 minutes and checking the status code of the HTTP responses.

There are several services that offer status monitoring online. They each have similar core features and a few niche features. That said, UptimeRobot is arguably the go-to tool for this task. It provides a free status monitoring service and can handle very large websites as well.

UptimeRobot Monitoring Page

UptimeRobot is a deep and customizable SaaS. It provides status monitoring, status reporting, incident management, maintenance windows, and API & integrations. However, most features are not included under the free plan.

For example, here is an example status page for my Django website:

UptimeRobot Status Report Page

The beauty of such a service is that it can differentiate between different HTTP responses. Generally, status codes from 200 to 399 are success HTTP responses; they mean the website is up and returning something sensible. 400–599 usually mean something is broken: either something is wrong on the client side or the server side. UptimeRobot can report these cases, although not detailed like Sentry.

In the rest of the article, I am going to show how we can implement a very simple, yet efficient Django endpoint for UptimeRobot so that we can check for uptime status. First of all, register for a free account on UptimeRobot here.

Implementing UptimeRobot for Django

Assuming you have already registered and have a Django project deployed on the web, we can continue.

In the free plan, as of this writing, UptimeRobot supports up to 50 endpoints. Usually, in a simple Django application you need only a few endpoints to check for uptime.

Initially, it might make sense to use the homepage/landing page as the main endpoint to check. After all, it is the main page most people land on. It should be up and running at all times!

While it makes sense to think like that, it is not entirely correct. The rule of thumbs is that, if one endpoint is running without a problem, then your landing page also is. This is because they share so much in common: the same architecture, database, server, and routes.

Therefore, it is very common to write a dead-simple Django view that just returns HTTP 200 for uptime monitoring. This is neat if you think about it; this approach avoids all the overhead that comes from HTTP request for the main page: HTML template rendering, CSS, JS, and image loading, the fetching of external libraries like Google Fonts.

So, for strict uptime monitoring, most Django developers write a small Django view like this:

# core/views.py

from django.http import HttpResponse
from django.views import View

class UpTimeCheckView(View):
    def get(self, request, *args, **kwargs):
        return HttpResponse("OK", content_type="text/plain")

And they embed this in their url routing:

# urls.py

from core.views import UpTimeCheckView
from django.urls import include, path
# Other imports go here... 

urlpatterns = [
    path("uptime-check/", UpTimeCheckView.as_view(), name="uptime-check"),
    # Other URLs go here...
]

Elegenat, innit? Now, you put this endpoint in UptimeRobot. Here is how you get an uptime monitoring service in less than 10 minutes for your Django website.

Of course, this service is very configurable and scalable. But for the most part, this single endpoint is quite useful in determining how well your site is running over a period of time.