Mysterious 500 Error with NO Traceback, and empty Exception Location

I have a project on render on the Starter plan (at $7/month == 512 MB RAM, 0.5 CPU) using PostgreSQL at the Basic-256mb plan, with 1 GB disk.
These resources are currently more than enough.

I have setup my django project such that when a customer visits:
/products/1205, the server looks for a valid URL, but doesnt find one, then it looks further, and in short, auto sends a Permanently moved response and redirects to
/products/1205/ (this is the actual URL, because it found a valid URL by adding a slash at the end)
This is done by default from Django using APPEND_SLASH setting as most of you would know.

Now, when I run my production environment (or my development environment), I get no errors when visiting the wrong URL “/products/1205”; it correctly redirects to “/products/1205/”
BUT
after approximately 12-18 hrs from when I do the latest deploy, a weird error occurs:
visiting the URL “/products/1205” gives me a 500 Server error. The auto-error email logs Django automatically sends to me show that there was NO traceback for these errors where Appending a slash results in a valid url.

Report at /products/mb-19
Internal Server Error: /products/mb-19
Request Method:	GET
Request URL:	https://hitecbearings.com/products/mb-19
Django Version:	5.0.8
Exception Location:	, line , in
Python Executable:	/opt/render/project/src/.venv/bin/python
Python Version:	3.10.12
Python Path:	
['/opt/render/project/src',
 '/opt/render/project/python/Python-3.10.12/lib/python310.zip',
 '/opt/render/project/python/Python-3.10.12/lib/python3.10',
 '/opt/render/project/python/Python-3.10.12/lib/python3.10/lib-dynload',
 '/opt/render/project/src/.venv/lib/python3.10/site-packages']
Server time:	Fri, 11 Jul 2025 00:35:19 +0000
Traceback
None
Request information
USER
AnonymousUser

GET
No GET data

POST
No POST data

FILES
No FILES data

COOKIES
No cookie data

As can be seen, the EXCEPTION LOCATION is empty etc.

I am using a custom 404 html template (if that’s relevant)

{% extends "partials/base.html" %}
{% load static i18n host_tags %}

{% block title %}404{{ block.super }}{% endblock title %}

{% block body %}
<div class="container-narrow" id="404-page-container">
  <h1 class="display-2 fw-semibold text-center">404</h1>
  <p class="my-3 text-center fs-5">{% trans "Oooops. Page not found." %}</p>
  <p class="my-3 text-center fs-5">{% trans "If you think this is wrong, consider contacting us" %}<a href="{% url 'home:contact_us' %}"> {% trans "here" %}</a></p>
</div>
{% endblock body %}

The 404.html template doesn’t have any issues and correctly displays the template wherever it should. The template base.html which 404.html extends has some variables which are populated from some custom context_processors.

Everything works fine for the development environment, and also for the first few hours in the production environment, as I highlighted above. Then I get this 500 error for seemingly no reason.

I am not sure if this is a render issue, or a django issue? Please highlight anything that comes to your mnd

I have tried clearing render’s build cache & deploying, restarting the service, restarting the database service, but the error is still there.

Please highlight the issue, render config seems correct (but the issue might well be from that side)

Please note that these issues arise when I change nothing from the admin dashboard, nor from render, observed after I do the latest deploy.

hi @HaseebAdnan0, this is something very strange yet not completely unexplainable.

Because if you have configured AdminEmailHandler for django you may receive an “empty” error email when one of your views returns a 5xx response by itself, because every 5xx response emits a log at ERROR level. Then this may be caused by some app or middleware which may be hiding a real exception (or something else).

Which django apps do you have installed?
Which middleware is configured?
Which logging configuration do you actually use?

Hi, thanks for taking your time out!

Which django apps do you have installed?

INSTALLED_APPS = [
    # Third Party Apps:
    'django_recaptcha',
    'jazzmin',
    'modeltranslation',
    'django_extensions',
    'crispy_forms',
    "crispy_bootstrap5",
    'taggit',
    'django_ckeditor_5',

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.sitemaps',

    # Custom Apps:
    'userauths',
    'home.apps.HomeConfig',
    'blog.apps.BlogConfig',
]

Which middleware is configured?

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.BrokenLinkEmailsMiddleware',
    'hitec.middleware.SetLanguageMiddleware',  # Set default language based on domain before LocaleMiddleware
    'django.middleware.locale.LocaleMiddleware',  # LocaleMiddleware will respect user preferences
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Which logging configuration do you actually use?

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse',
        },
    },
    'formatters': {
        'django.server': {
            '()': 'django.utils.log.ServerFormatter',
            'format': '[{server_time}] {message}',
            'style': '{',
        }
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'formatter': 'django.server',
        },
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler',
            'include_html': True,  # For nicely formatted HTML emails
        },
    },
    'loggers': {
        'django': {
            'handlers': ['console'],
            'level': os.getenv('DJANGO_LOG_LEVEL', 'INFO'),
            'propagate': True,
        },
        'django.request': {
            'handlers': ['mail_admins', 'console'],
            'level': 'ERROR',
            'propagate': True,
        },
    },
    'root': {
        'handlers': ['console'],
        'level': 'WARNING',
    },
}

It would help a lot if I can actually see the traceback.

Important new discoveries

The 500 error not being there right after deploy, but surfacing 12-18 hr after wasnt random. What happens is that when excessive bots are crawling the website, and I am not using cache in my custom context_processors (yet), so obv there is a lot of queries to the database, which can max out. after maxing out for around ~1 min, render.com will automatically restart the service since maxing out makes the database unavailable to new connections.
So when render automatically restarts the database service, I can see some OperationalErrors logged to my e-mail, which arise due to requests during this restart. And after that, the “mysterious” errors get logged to my email with no information.

Lately (just now), I have configured my context_processor to explicitly handle exceptions (Sorry :sweat_smile: for not doing that before), so that in case of an exception, we pass default values, which should stop any errors from arising in rendering base.html.

My conn_max_age is 600, and I also added CONN_HEALTH_CHECKS = True to settings.py. After adding the CONN_HEALTH_CHECKS, I reproduced the errors by getting a crawler to crawl my website, and I discovered that now, I get 500 error for only some of the requests, but it works fine with others. (for e.g: /products/1203 correctly redirects to /products/1203/, while /products/5216 results in an error), which can mean that the 500 error is arising due to using a bad connection. Although the conn_max_age is 10 minutes, the 500 errors are still there after 1 hour, so maybe this theory of bad connections created due to the OperationalErrors is wrong.

Another significant thing to note is that the 500 error is not just occuring where appending a slash would result in a valid URL, but its occuring everywhere we should have gotten a 404 (which is why I am thinking the issue might be from rendering 404.html, which extends from base.html.

Since base.html uses variables from my custom context_processor, which would previously give empty values instead of default values when there is an OperationalError, the solution might very well be here, so I will get back to you after I reproduce the conditions for this error, and check if my handling exceptions in OperationalError and returning default values makes any difference.

If not, I will also try using a minimalistic 404.html template, and again reproduce the error and update here.

Regardless, it had help a lot if the errors are properly logged, please do help me identify if there is any incorrect configuration with my logging settings.

You could use something like Sentry to get good reports of errors, which might help track this down.

Thanks for the suggestion, will check it out!

I’m seeing the same behavior; sometimes visiting locations without a trailing / will trigger a 500 error, sometimes what should be a 404 error will trigger it, and other times everything works as expected. There’s never a traceback, and it seems much harder to reproduce locally but it happens fairly consistently in production, although it’s still intermittent.

@HaseebAdnan0 you were able to shed a good amount of light on this so I appreciate you sharing your findings. Did you ever get to the bottom of this?