An event logger
Clone or download
grahamu Merge pull request #27 from pinax/set_null
Use Use SET_NULL so Log instances are not deleted when related object is deleted
Latest commit 805d1c4 Jan 23, 2018

Pinax Eventlog

CircleCi Codecov

Table of Contents

About Pinax

Pinax is an open-source platform built on the Django Web Framework. It is an ecosystem of reusable Django apps, themes, and starter project templates. This collection can be found at



pinax-eventlog is a simple app that provides an easy and clean interface for logging diagnostic as well as business intelligence data about activity that occurs in your site.

By default this app writes directly to the database.

For small sites, it should be good enough to use inline but you might want to consider wrapping calls to the log() method and queue them in a job manager like celery or pyres so that the calls become asynchronous.

Supported Django and Python versions

Django \ Python 2.7 3.4 3.5 3.6
1.11 * * * *
2.0 * * *



Install the package:

    $ pip install pinax-eventlog

Add pinax.eventlog to your INSTALLED_APPS setting:

        # other apps

Run the app's migrations:

    $ python migrate eventlog


Using pinax-eventlog is pretty simple. Throughout your site, you just call a single function, log() to record whatever information you want to log. If you are wanting to log things from third party apps, your best bet is to use signals. Hopefully the app in question provides some useful signals, but if not, perhaps some of the built in model signals will be enough (e.g. pre_save, post_delete, etc.)


from pinax.eventlog.models import log

def some_view(request):
    # stuff is done in body of view
    # then at the end before returning the response:
            "title": foo.title
    return HttpResponse()

The action parameter can be any string you choose. By convention, we always use all caps. Take note, however, whatever you choose, will be the label that appears in the admin's list filter, so give it some thought on naming conventions in your site so that the admin interface makes sense when you have 50,000 log records you want to filter down and analyze.

The extra parameter can be anything that will serialize to JSON. Results become easier to manage if you keep it at a single level. Also, keep in mind that this is displayed in the admin's list view so if you put too much it can take up a lot of space. A good rule of thumb here is put enough identifying data to get a sense for what is going on and a key or keys that enable you to dig deeper if you want or need to.


You can also easily make your class based views auto-logged by using the pinax.eventlog.mixins.EventLogMixin. The only requirement is defining an action_kind property on the view. But you can also override a number of properties to customize what is logged.


There is a signal that you are setup a receiver for to enable you to trigger other actions when an event has been logged:

event_logged provides an event object as an argument that is the event that was just logged.

Change Log


  • Use SET_NULL so Log instances are not deleted when related object is deleted
  • Update
  • Update CI configuration
  • Update jsonfield requirement




  • Standardize and improve documentation


  • Add Django 2.0 compatibility testing
  • Drop Django 1.8, 1.9, 1.10 and Python 3.3 support
  • Convert CI and coverage to CircleCi and CodeCov
  • Add PyPi-compatible long description
  • Move documentation to


  • Fix spelling error in documentation
  • Added wheel release
  • Dropped 3.2 support


  • Added missing migration from the switch to jsonfield


  • Started testing against Django master
  • Switched to jsonfield from django-jsonfield
  • Added ability to link a log to any object via a GFK
  • Added ability to override timestamp
  • Fixed template fragment path


  • Eldarion donated to Pinax, renaming from eventlog to pinax-eventlog


  • added the ability to link content objects you are logging about


  • added property to provide template fragment name


  • Add mixin for making it easy to audit CBV


  • removed non-working templatetag
  • update setup to work with Python 3.3+


  • remove pusher integration
  • support for custom user model


  • added the event_logged signal
  • corrected typo in usage documentation


  • attempts at fixing admin performance


  • attempts at fixing admin performance


  • attempts at fixing admin performance with an index on action


  • attempts at fixing admin performance with an index on timestamp


  • update to use install_requires instead of setup_requires


  • made the extra argument optional


  • improve the admin


  • use instead of for timestamp


  • when a user is deleted set FK to null instead of losing data


  • bumped version on django-jsonfield


  • added docs


  • initial release


This project was originally named eventlog and was created by the team at Eldarion. It was later donated to Pinax and at that time renamed to pinax-eventlog.


For an overview on how contributing to Pinax works read this blog post and watch the included video, or read our How to Contribute section. For concrete contribution ideas, please see our Ways to Contribute/What We Need Help With section.

In case of any questions we recommend you join our Pinax Slack team and ping us there instead of creating an issue on GitHub. Creating issues on GitHub is of course also valid but we are usually able to help you faster if you ping us in Slack.

We also highly recommend reading our blog post on Open Source and Self-Care.

Code of Conduct

In order to foster a kind, inclusive, and harassment-free community, the Pinax Project has a code of conduct. We ask you to treat everyone as a smart human programmer that shares an interest in Python, Django, and Pinax with you.

Connect with Pinax

For updates and news regarding the Pinax Project, please follow us on Twitter @pinaxproject and check out our Pinax Project blog.


Copyright (c) 2012-2018 James Tauber and contributors under the MIT license.