Overview
Recently, we encountered an intermittent downtime alert from UptimeRobot for our Django-based web application. The alert was perplexing because it didn’t indicate a true downtime — instead, it flagged a “Keyword not found” issue on the login page:
URL Monitored:
https://xyz.zzyy.com/accounts/login/?next=/
Error Message:
Response: Body: empty, header: {}
Detected by: Dallas, USA (UptimeRobot node)
The page was supposed to contain a specific keyword that UptimeRobot monitors, but the keyword was missing in some responses — even though the HTTP status code was 200 OK.
This blog covers the root cause analysis, diagnostic steps, and resolutions we applied to restore reliability and ensure uptime monitoring reflects real availability.
Symptoms & Why It’s a Problem
Empty or partial page responses returned intermittently.
UptimeRobot triggered alerts even though the site was technically up.
End users may rarely receive an incomplete response (blank login page).
Possible long-term degradation if left unresolved.
Step-by-Step Diagnosis
We broke the investigation into multiple areas, considering both infrastructure and application-level factors.
1. Confirm the Problem Isn’t False Positive
We reproduced the UptimeRobot call using curl:
curl -A “UptimeRobot/2.0” -v https://xyz.zzyy.com/accounts/login/?next=/
This occasionally returned a 200 response with an empty body, confirming it was not a false alert.
2. Hypotheses We Considered
uWSGI worker getting stuck or killed – Yes – Long requests may hang silently
Template rendering failures – Yes – Dynamic content may fail intermittently
Nginx timeout or buffering issues – Partially -Not a likely root cause here
Bot detection or rate-limiting – Yes -Could block UptimeRobot
Firewall or Fail2Ban blocking – Yes -We checked for IP blocks or bans
CSRF/session causing render issues – Yes -Not relevant for login GET
Cache miss or rebuilding – Yes -Less likely, no major cache system
Too few workers under traffic spike – Yes -Resource limitation can cause incomplete responses
3. Reviewing uWSGI Configuration
We checked our existing uwsgi.ini, which was minimal and lacked robustness:
module=filimin_internal.wsgi:application master=True vacuum=True socket=/home/pankaja/filimin_internal/django.sock chmod-socket=777
Issues Identified:
No timeout protection (harakiri)
No request recycling (max-requests)
Socket permissions were too loose (chmod-socket=777)
Fix: Updated uwsgi.ini for Stability
We applied a minimal yet powerful update:
[uwsgi] module = filimin_internal.wsgi:application master = True vacuum = True chmod-socket = 777 # (Consider using 660 with uid/gid for production) processes = 20 max-requests = 1000 # Harakiri: kill requests running longer than 60 seconds harakiri = 60 harakiri-verbose = true
Why These Settings Matter:
Setting Purpose
processes = 20 Handles higher concurrency during load
max-requests = 1000 Recycles workers before they degrade
harakiri = 60 Kills hung requests after 60 seconds
Deployment: Safe Update Procedure
To apply the .ini changes on a live DigitalOcean production server:
# Backup original cp uwsgi.ini uwsgi.ini.bak # Edit the file nano uwsgi.ini # Restart uWSGI (systemd example) sudo systemctl restart uwsgi
Or if running without systemd:
# Reload with kill -HUP or touch if using Emperor mode ps aux | grep uwsgi kill -HUP <PID>
Validation After Fix
We simulated UptimeRobot requests again using curl.
All responses now contained the correct keyword consistently.
No further downtime alerts were triggered post-deployment.
Root Cause: Intermittent Worker Hang or Overload
The actual root cause was likely a combination of:
Occasional request hangs, where a worker would get stuck and return an incomplete response.
No harakiri, so the worker never recovered from the stuck request.
Worker degradation over time — no recycling (max-requests) allowed memory issues to persist.
Bonus Tip: Don’t Rely on Login Page for Health Checks
Instead of monitoring /accounts/login/, use a dedicated health check URL like /healthz:
# urls.py
path("healthz/", lambda r: HttpResponse("OK - filimin-health", status=200))
Then, in UptimeRobot, look for keyword “filimin-health” on /healthz.
This ensures:
Predictable response
No auth/session logic involved
No template rendering issues
🧠 Final Thoughts
This incident reminds us that 200 OK isn’t always OK. A server returning an incomplete or blank response can go undetected without proper monitoring, recycling, and timeout management.
If you’re running Django with uWSGI and Nginx:
✅ Always use harakiri to kill stuck requests
✅ Enable max-requests to prevent degraded worker state
✅ Consider dynamic worker scaling (cheaper mode)
✅ Monitor worker health with tools like uwsgitop
📌 Need Help?
If you’re running into similar stability issues, or need help setting up proper uptime monitoring, Nginx/uWSGI tuning, or Django performance profiling, feel free to reach out or drop a comment below.