Monitoring Graphene Django Python GraphQL API Using Sentry
Read about How To Set Up Sentry With Your Python GraphQL API In 5 Minutes
As engineering teams are adopting CI/CD practices, software products are getting delivered faster than ever. Error monitoring comes in handy as it provides developers the confidence to deploy faster while knowing there’s a safety net watching their deployments.
On top of that, having error monitoring helps developers to fix and debug errors faster, in order words, developers can spend more quality time building new high-quality features.
The goal of this post is to document and share some of the issues and tips that I have learned while I was working on setting up Sentry monitoring with Django Graphene projects.
By the end of this post, you would be able to know:
- How to hide or ignore
Traceback (most recent call last)logger errors - How to log Sentry errors with Django Graphene using middleware
- How to monitor your GraphQL query performance on Sentry
- How to log each GraphQL operation correctly on Sentry
Getting Started With Django
For starters, you can easily set up your Django projects with Sentry by following the official documentation here.
Here’s an example of a settings.py with sentry SDK:
# settings.py
import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration
from sentry_sdk.integrations.logging import ignore_logger
dsn=YOUR_SENTRY_PROJECT_DSN,
integrations=[DjangoIntegration()],
traces_sample_rate=1.0,
send_default_pii=True,
environment=YOUR_PROJECT_ENVIRONMENT,
)Check out Sentry’s documentation to understand what these configuration options mean.
Traceback Error Spams
Problem
As I was using the default setup while working with Graphene, I ran into issues where my Django Graphene project was getting spammed with this Sentry issue:

Sentry was getting spammed with Traceback (most recent call last) errorLooking from the Sentry issue, as this error message isn’t particularly meaningful, nor actionable — which can cause error fatigue in the long run, we chose to ignore it.
Solution
In order to get around this, simply ignore this by using ignore_logger fromsentry_sdk .
In this case, we would be ignoring the graphql.execution.utils , which is the source of the Traceback errors.
# settings.pyfrom sentry_sdk.integrations.logging import ignore_loggerignore_logger('graphql.execution.utils')You can easily ignore other loggers with this method too!
Error Monitoring
Problem
As we try to forward exceptions to Sentry, there was an apparent issue where Graphene Django would swallow everything, especially after ignoring the graphql.execution.utils logger.
Solution
One of the recommended solutions here is to use create and use middleware inside your Graphene settings.
Start by creating a simple SentryMiddeware to capture all the exceptions thrown.
# middlewares.pyclass SentryMiddleware(object):
def on_error(self, error):
capture_exception(error)
raise error def resolve(self, next, root, info: ResolveInfo, **args):
return next(root, info, **args).catch(self.on_error)Next, simply add the newly created SentryMiddleware to your GRAPHENE setting inside your settings.py .
# settings.pyGRAPHENE = {
'SCHEMA': 'project.schema.schema',
'SCHEMA_OUTPUT': 'schema.graphql',
'MIDDLEWARE': [
# ...
'django_graphene_starter.middlewares.SentryMiddleware',
],
}
While this is much better than just Traceback error, the operation name /graphql is still rather inaccurate.
Ideally, this should be named as the operation name of your GraphQL query or mutation, i.e. updateArticle , createPublication etc. We will work on naming each query and mutation correctly next.
Performance Monitoring
Besides error monitoring, Sentry is able to track your software performance by measuring metrics such as throughput and latency. Here’s the official documentation to set up performance monitoring for your Django project.

To set this up with your Django Graphene project, you would need to create a custom GraphQLView.
from sentry_sdk.api import start_transaction
from graphene_django.views import GraphQLViewclass CustomGraphQLView(GraphQLView):
def execute_graphql_request(
self,
request: HttpRequest,
data,
query,
variables,
operation_name,
show_graphiql,
):
with start_transaction():
return super().execute_graphql_request(request, data, query, variables, operation_name, show_graphiql)
Problem
From the code snippet above, each of your GraphQL requests will now be logged under the performance tab on Sentry. Though now we have another problem — all our transactions are being named as /graphql , while the operation is always http.server
We don’t have a clear idea of what we’re looking at or what we’re tracking.
Solution
Let’s get the operation type and operation name from Graphene.
# views.pyclass CustomGraphQLView(GraphQLView):
def execute_graphql_request(
self,
request: HttpRequest,
data,
query,
variables,
operation_name,
show_graphiql,
):
operation_type = (
self.get_backend(request)
.document_from_string(self.schema, query)
.get_operation_type(operation_name)
)
with start_transaction(op=operation_type, name=operation_name):
return super().execute_graphql_request(
request, data, query, variables, operation_name, show_graphiql
)Let’s run our GraphQL query/mutation again:
mutation updatePublication($input: UpdatePublicationInput!) { # NOTE
updatePublication(input: $input) {
publication {
id
title
}
}
}# NOTE: We need to make sure that we name this mutation accordingly

Conclusion
Error monitoring improves your applications’ health by providing useful insights into the stability of your software.
On top of that, developers can use these insights for addressing existing technical debts and make better decisions around building new features versus fixing bugs.
I had a lot of fun integrating Sentry with my Django Graphene project, feel free to look at my public project on GitHub as a reference.
I hope you find this article helpful! Happy coding!
