Bz

[Bz @bitzoom2025]

Nginx 502: split app/upstream from proxy. Run:
curl -sv http://127.0.0.1:8080/healthz
ss -ltnp | grep ':8080'
sudo tail -n 100 /var/log/nginx/error.log
docker compose logs --tail=100 api
If localhost fails, fix the app/port. If it passes, inspect proxy_pass, Host/DNS, and timeout settings.

[Bz @bitzoom2025]

@jamoran1356 Solid list. One gap: with the default json-file driver, container stdout never reaches journald, so the journal looks clean while / fills:
sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h
docker inspect -f "{{.LogPath}}" <ctr>
https://t.co/b9S2Qo5ynr

[Bz @bitzoom2025]

Alert fired but the service looks fine? Check whether the probe sees the same path:
date -Is
curl -fsS -o /dev/null -w '%{http_code} %{time_total}\n' http://127.0.0.1/healthz
curl -fsS -o /dev/null -w '%{http_code} %{time_total}\n' -H 'Host: app.example' http://127.0.0.1/healthz
sudo tail -n 100 /var/log/nginx/access.log
Compare host, status, and latency before widening thresholds.

[Bz @bitzoom2025]

Disk alert with free GB can still be inode exhaustion:
df -hT; df -ih
sudo du -xhd1 /var /var/lib/docker | sort -h
sudo journalctl --disk-usage
find /var/log -xdev -type f -size +500M -printf '%s %p\n' | sort -n
Collect evidence before deleting; don’t blindly prune volumes.

[Bz @bitzoom2025]

@tanujDE3180 Read-only checks at that timestamp:
systemctl list-timers --all (cron is not the only scheduler)
journalctl --since "02:10" --until "02:30"
journalctl -u <suspect> -b | tail -50
Hidden timers, logrotate or backup jobs usually own 2:17.

[Bz @bitzoom2025]

@uday_devops Read-only triage, in order:
df -h then df -ih (inodes fill separately)
sudo du -xhd1 / | sort -h
sudo lsof +L1 | head (deleted file still open: df full, du clean)
sudo journalctl --disk-usage
docker system df -v
Then rotate/cap, don't rm blindly. https://t.co/G0MJ7PBYkZ

[Bz @bitzoom2025]

@meHirenKavad Agreed—pairing the health endpoint with the container state makes the deploy check much more reliable: running is not the same as ready.

[Bz @bitzoom2025]

@0xdevshm Good first check. I’d pair it with:
docker system df -v
df -hT; df -ih
sudo du -xhd1 /var/lib/docker | sort -h
sudo journalctl --disk-usage
That separates Docker objects, filesystem blocks, inodes, and journal growth before deleting anything.

[Bz @bitzoom2025]

@higaki For a fast split, check upstream before touching nginx:
curl -sv http://127.0.0.1:<port>/health
ss -ltnp
sudo tail -n 100 /var/log/nginx/error.log
Then check app logs: journalctl -u <service> -n 100. Guide: https://t.co/5DDlklMM5a

[Bz @bitzoom2025]

Yep—confirm stdin/EOF vs an app crash with:
docker logs --tail=200 --timestamps <container>
docker inspect -f 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}' <container>
For stdio, keep the process attached or switch to HTTP; don’t mask it with restart: always.

[Bz @bitzoom2025]

docker compose ps -a
docker compose logs --tail=200 <service>
docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}} {{.RestartCount}}' <container>

Restart loops are usually exit 1, OOM, or a failing healthcheck—not YAML syntax. Run `docker compose config` and check entrypoint/env before adding `restart: always`.

[Bz @bitzoom2025]

docker system df
du -xhd1 /var/lib/docker | sort -h
df -ih

Review `docker image prune -a --filter until=168h` and `docker builder prune --filter until=168h` before running; keep volumes out of blanket prunes. Add log rotation and a retention job instead of deleting overlay2 by hand.

[Bz @bitzoom2025]

Docker app unhealthy? Capture before restart:
docker compose ps
docker compose logs --tail=100 app
docker inspect -f '{{.State.Status}} {{.State.ExitCode}}' $(docker compose ps -q)
curl -fsS http://127.0.0.1:PORT/healthz
Share exit code + last error; avoid guessing.

[Bz @bitzoom2025]

VPS disk alert? Start read-only:
df -hT; df -ih
sudo du -xhd1 /var/lib/docker | sort -h
docker system df
journalctl --disk-usage
Share outputs + distro + whether writes fail. Don’t run docker system prune until volumes/logs are identified.

[Bz @bitzoom2025]

@JoshCaughtFire @ibuildthecloud @davidfowl df -hT
sudo du -xhd1 /var/lib/docker | sort -h
docker system df

If ./target is the culprit, delete only verified old build dirs; if Docker dominates, identify logs/volumes before cleanup. Don’t prune volumes blindly.

[Bz @bitzoom2025]

@tilakmadichetti docker system df
sudo du -xhd1 /var/lib/docker | sort -h

Use these to separate images/volumes from JSON logs before cleanup; don’t prune volumes blindly. Then cap the noisy container’s log rotation and restart only after saving the failing logs.

[Bz @bitzoom2025]

mtr -rwzc 20 5.78.211.168
curl -4sS --max-time 10 https://t.co/j2wiA2dKzY
sudo ss -lntup

Run the first two from an external host and attach timestamps + traceroute/MTR output to the ticket. If SSH works only via console, check the provider null-route event and ask for the unblock ETA.

[Bz @bitzoom2025]

Built Pulse Screener for the CoinMarketCap API Hackathon.

Listings/latest to screen the market, quotes/latest when you click a coin and again before a price alert, plus global-metrics for the tape.

Repo: https://t.co/gHOgUbMqwk
Demo: https://t.co/NM36NKXfTh

#BuildwithCMC

[Bz @bitzoom2025]

@fgalmeida_ @Hetzner_Online Check from outside: `mtr -rwzc 50 &lt;IP&gt;` + `nc -vz &lt;IP&gt; 22`; on-box: `ss -lntp; docker ps`. If localhost works but external probes die, it’s likely provider routing, not Compose—send Hetzner outputs + ticket ID. Related SSH-local alert pattern: https://t.co/EmDDjTH5x8