Skip to main content

Generate static error pages (502 etc) for when your app is failing

Project description

So... obviously you are a fantastic programmer who never writes a bug and a fantastic systems administrator who never lets your app go down. But what about the rest of us?

Sometimes the upstream app process (e.g. gunicorn) that runs your Django website goes down, and your frontend webserver (e.g. nginx) has to serve a 502 error page to visitors.

This gives you three options:

  • Just use whatever the default error pages are within frontend server. They will be very ugly and embarrassing.

  • Create custom error pages that match your site's styling. Perhaps you deploy them out as static files and point your frontend server at the right location. This starts out great, but as you change your site styling the static error pages will get out of sync. You will create work for yourself to keep them updated.

  • Use this django-downpage project! It provides a downpagegenerate command which can be run just after running collectstatic. It will build static error pages from templates. They will always be up-to-date, but will also be available as static resources even when the app server goes down.

Usage:

Before starting it is recommended to ensure that handler404 and handler500 error pages have already been configured (as documented here and here). Your templates from these views can serve as the basis for the templates that downpage will use.

Install django-downpage from PyPI as with any other dependency. To quickly get started you might run:

$ pip install django-downpage

although for production usage it would be more manageable to use a requirements.txt or equivalent.

Now edit your settings.py to ensure downpage is listed as an installed app. The order is not significant:

INSTALLED_APPS = [
    # ...snip...
    "downpage",
    # ...snip...
]

Also in settings.py you will need to define the list of pages that should be built:

DOWNPAGE_PAGES = [
    ("502.html", "myapp/downpage_502.html"),
    ("503.html", "myapp/downpage_503.html", {"name", "Service Unavailable"}),
    ("504.html", "myapp/downpage_504.html"),
    # ...etc...
]

The first element of the tuple is the destination file that will get built, relative to the STATIC_ROOT directory. The second element is the template name, and is compatible with any name that can be understood by the render(...) function that is a built-in shortcut. An optional third element defines extra context that will be supplied to the template when it is rendered.

At this point you need to create your templates. A good starting point would be the pages served up for 404 or 500 errors. You can use the same template for each generated page if you wish, using extra context to customise them. Also, if you have already set your site up to support the new-style Jinja2 templates then they will work with no extra configuration needed.

Now update whatever process you use for deployment. You presumably already call manage.py collectstatic as part of this process. The downpagegenerate management command is best run immediately after this:

# ...snip...
/path/to/virtualenv/bin/python manage.py collectstatic
/path/to/virtualenv/bin/python manage.py downpagegenerate
# ...snip...

Then you need to set up your frontend server to be aware of these files. That will vary depending on the server you use.

Example: Configuring an Nginx Frontend:

If your frontend webserver is Nginx then you presumably already have some config that looks something like this:

location /static {
    alias /path/to/static.collected/;
}

location / {
    include proxy_params;
    proxy_pass http://localhost:8000;
}

So add in an error_page directive for each type of error that you want to handle:

location / {
    include proxy_params;
    proxy_pass http://localhost:8000;
    error_page 502 /static/502.html;
    error_page 503 /static/503.html;
    error_page 504 /static/504.html;
}

Postscript:

This code is licensed under the BSD three-clause licence.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django-downpage-1.2.1.tar.gz (5.3 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

django_downpage-1.2.1-py3-none-any.whl (5.9 kB view details)

Uploaded Python 3

File details

Details for the file django-downpage-1.2.1.tar.gz.

File metadata

  • Download URL: django-downpage-1.2.1.tar.gz
  • Upload date:
  • Size: 5.3 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/5.1.1 CPython/3.11.2

File hashes

Hashes for django-downpage-1.2.1.tar.gz
Algorithm Hash digest
SHA256 4610d7e9ecd68cb93634782fd729c8579cafdb89cbf087074110b74d6c4b0eee
MD5 9a32c5917da0014f1ef166806bf031f3
BLAKE2b-256 3b75cc72b921fe5e599429f0e07619647b56c635241e60d856c747e10a802752

See more details on using hashes here.

File details

Details for the file django_downpage-1.2.1-py3-none-any.whl.

File metadata

File hashes

Hashes for django_downpage-1.2.1-py3-none-any.whl
Algorithm Hash digest
SHA256 a4231997791f3cb7b599eda69ffc4b0a858493487c46d73087ee77861a8d18f4
MD5 1d4577ef0791645e0709ff42059de167
BLAKE2b-256 081f9416d525c54e9e371789b5efd9809d6c4bf0cca18cef7f943658507d2c75

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page