Sentry advantages over Django's error email reports for small dev teams?


Our Sentry plan recently expired and I was wondering how keeping using Sentry could benefit our small dev team, vs. just getting error email reports from Django.

The only error reporting we’re using so far is from integration with Dogslow, which can also integrate with Django’s email error reporting (in which case more detailed information (stack variables) can actually be sent, which seems not possible with the Sentry integration).

I can easily see the benefits of Sentry for medium to large dev teams, with releases, issues management etc., but I’m wondering if I’m there core features which I’m not aware of which could benefit small dev teams.


We provide significantly more context and debug capabilities, similar to the DEBUG = True flag, but we do it in production. Additionally we capture things like who is affected by the issue, so if it’s say a billing issue you have email addresses that you can follow up with.

IMO it’s equally valuable for a small team as it is a larger team, but the day-to-day use will be slightly different.

Interesting, I see the stack variables are captured with regular Django errors. This is great and indeed much more informative.

I notice that in Dogslow the situation is reversed - it doesn’t send its own captured stack variables when integrated with Sentry, even when the setting for it is turned on, while it does send those variables when configured to send via email.
From looking at the code, it looks like it’s because Dogslow thinks it has no API available for sending it. Is this an outdated assumption in the Dogslow code, in which case I can open an issue there, or is this a limitation of the Sentry API?

It’s very possible that this is just an issue in Dogslow. Unless they’re doing something fairly sketchy with exceptions it should always be available.