Posts

You’ve deployed your webhook endpoint. The external service says it’s sending requests. But your logs show nothing. Here’s how to systematically debug incoming webhook issues. The Debugging Checklist Before diving deep, run through these quick checks: 1 2 3 4 5 6 7 8 9 10 11 # 1. Is your endpoint actually reachable? curl -X POST https://your-domain.com/webhook \ -H "Content-Type: application/json" \ -d '{"test": true}' \ -w "\nHTTP Status: %{http_code}\n" # 2. Is DNS resolving correctly? dig your-domain.com +short # 3. Is the port open? nc -zv your-domain.com 443 If your own curl request doesn’t reach the endpoint, the problem is infrastructure. If it does but the external service’s requests don’t arrive, the problem is somewhere in between. ...

Your container is restarting. Over and over. docker ps shows it’s been up for 3 seconds, then 5, then 2. You’re stuck in a loop and the logs aren’t helping. Here’s how to debug it systematically. Step 1: Check the Exit Code 1 docker inspect --format='{{.State.ExitCode}}' container_name Common exit codes: 0: Clean exit (container finished its job) 1: Application error (check your code) 137: OOMKilled (out of memory) 139: Segfault 143: SIGTERM (graceful shutdown) If you see 137, your container is being killed for using too much memory. Skip to the OOM section below. ...

You refresh your page and see it: 502 Bad Gateway. Nginx is telling you something went wrong, but what? This guide covers the most common causes and how to fix each one. What 502 Bad Gateway Actually Means A 502 error means Nginx (acting as a reverse proxy) tried to contact your upstream server (your app) and either: Couldn’t connect at all Got an invalid response The connection timed out Nginx is working fine. Your upstream is the problem. ...

You’ve written a script. You test it manually: ./my-script.sh — works perfectly. You add it to cron, wait for the scheduled time… nothing happens. No output, no errors, just silence. This is one of the most frustrating debugging experiences in Linux. Let’s fix it. The Core Problem: Cron Runs in a Different Environment When you run a script manually, you’re running it in your interactive shell with: Your PATH variable (with all your custom directories) Your environment variables (loaded from .bashrc, .profile, etc.) Your current working directory Your user’s full shell configuration Cron runs scripts in a minimal environment with almost none of this. That’s the root cause of nearly every “works manually, fails in cron” issue. ...

Your systemd service is “active (running)” but the application isn’t responding. No errors in systemctl status. The journal shows it started. Everything looks fine. Except it isn’t. This is one of the most frustrating debugging scenarios in Linux administration. Here’s how to actually figure out what’s wrong. The Problem: Green Status, Dead Application 1 2 3 4 5 $ systemctl status myapp ● myapp.service - My Application Loaded: loaded (/etc/systemd/system/myapp.service; enabled) Active: active (running) since Fri 2026-03-20 10:00:00 EDT; 2h ago Main PID: 12345 (myapp) Looks healthy. But curl localhost:8080 times out. What’s happening? ...

You’re using Python’s imaplib to search emails, but mail.search() keeps returning empty results even though you know matching emails exist. Here’s why it happens and how to fix it. The Problem 1 2 3 4 5 6 7 8 9 import imaplib mail = imaplib.IMAP4_SSL('imap.gmail.com') mail.login('user@gmail.com', 'app-password') mail.select('INBOX') # This returns nothing! status, messages = mail.search(None, 'FROM "john@example.com" SUBJECT "invoice"') print(messages) # [b''] You’ve verified the emails exist. You can see them in Gmail. But search() returns an empty byte string. ...

Your container starts, immediately dies, restarts, dies again. The docker ps output shows “Restarting (1) 2 seconds ago” and you’re watching it cycle endlessly. Here’s how to break the loop and find the actual problem. Step 1: Check the Exit Code First, figure out how it’s dying: 1 docker inspect --format='{{.State.ExitCode}}' container_name Common exit codes: 0 — Clean exit (shouldn’t restart unless you have restart: always) 1 — Application error (check logs) 137 — Killed by OOM (out of memory) 139 — Segmentation fault 143 — SIGTERM received (graceful shutdown request) Step 2: Read the Logs (Before They Disappear) Containers in restart loops lose logs on each restart. Catch them quick: ...

Your container builds fine, starts fine, then fails with Could not resolve host or Temporary failure in name resolution. Here’s how to fix it. Quick Diagnosis First, confirm it’s actually DNS and not a network issue: 1 2 3 4 5 6 7 8 # Get a shell in the container docker exec -it <container_name> sh # Test DNS specifically nslookup google.com # or cat /etc/resolv.conf ping 8.8.8.8 # If this works but nslookup fails, it's DNS If ping 8.8.8.8 works but nslookup google.com fails, you have a DNS problem. If both fail, it’s a broader network issue. ...

You wrote what looks like perfectly reasonable Python code: 1 2 3 4 5 6 7 8 9 10 11 12 import subprocess proc = subprocess.Popen( ["some-command"], stdout=subprocess.PIPE, stderr=subprocess.PIPE ) # Read the output output = proc.stdout.read() errors = proc.stderr.read() proc.wait() And it hangs. Forever. No error, no timeout, just… nothing. Welcome to the pipe buffer deadlock, one of Python’s most frustrating subprocess gotchas. Why This Happens The problem is OS pipe buffers. When you create a subprocess with stdout=subprocess.PIPE, the OS creates a pipe with a fixed buffer size (typically 64KB on Linux). ...

You wake up to angry messages. Your service has been down for hours. You check your monitoring dashboard — all green. What happened? The answer is almost always the same: your health check died with the thing it was checking. The Problem: Shared Failure Domains Here’s a common setup that looks correct but isn’t: ┌ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └ ─ ─ ─ ─ ─ ┌ │ │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ( ─ ─ ─ ─ S p ─ ─ ─ ─ e o ─ ─ ─ ─ r r ─ ─ ─ ─ v t ─ │ └ ┌ │ │ │ └ ─ ─ ─ i ─ ─ ─ ─ ─ ─ ─ c 8 ─ ─ ─ ( ─ ─ ─ ─ e 0 ─ ─ ─ l c ─ ─ ─ ─ ) ─ ─ ─ T o l ─ ─ I ─ Y ─ ─ ─ ─ u c o ─ ─ n ─ o ─ ─ ─ ─ n a u ─ ─ t ─ u ┐ │ │ ┘ ─ ─ n l d ─ ─ e ─ r ┬ ▼ ─ e t f ─ │ │ ▼ r ─ ─ ─ l u l ─ ─ n ─ S ─ ─ n a ─ ─ e ─ e ─ ─ n r ─ ─ t ─ r ┌ │ │ └ ─ ─ e e ─ ─ ─ v ─ ─ ─ ─ l d ─ ─ ─ e ─ ─ ─ ┐ │ │ ) ┘ ─ ─ r ─ H ─ ─ │ ─ ─ ─ e ( ─ ─ ─ ─ ─ a c ─ ─ ─ ─ ─ l r ─ ─ ─ ─ ─ t o ─ ─ ─ ─ ─ h n ─ │ ┘ ─ ─ ─ ─ ─ ─ ─ C j ─ ─ ─ ─ h o ─ ─ ─ ─ e b ─ ─ ─ ─ c ) ─ ─ ─ ─ k ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ │ ┘ ─ ─ ─ ─ ─ ┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ┘ The health check runs on the same server, uses the same tunnel, and sends alerts through… the same tunnel. When the tunnel dies, both the service AND the alerting die together. ...