Site down at 2 a.m.: the first 15 minutes when you're the only one on call
A fixed triage order: confirm impact, check resources, services and failure-window logs, then plan the smallest action and its rollback.
Updated
Server troubleshooting guides for developers and small teams
Start with the symptom you see. These guides work without OpsMate and separate diagnostic checks from changes to the server.
The site is suddenly down and I don't know servers
Without Linux or SSH, switch networks, check the cloud console, and save evidence. Continue with the 15-minute order after you can log in.
I can't manage a server. What should I do?
If you cannot manage a server, confirm who is affected, check the cloud console, save evidence, then decide who to call. Keep a panel if you already use one.
Connect your first server in 10 minutes: from sign-up to an SSH terminal in OpsMate
Add a test server with an SSH key, from sign-up to the OpsMate terminal. A host with no Docker, or a non-root user, still finishes discovery. Commands that fail the safety check are blocked and never run. Low-risk fixes run automatically by default, and every step is logged.
Check server logs with AI and SSH commands in one workspace
OpsMate puts SSH and AI on one page—ask in plain language when you forget commands, or type uptime/df yourself. Commands that fail the safety check are blocked and never run. Low-risk fixes run automatically by default, and every step is logged. Evidence stays in the terminal.
Remote server alerts in Telegram: investigate when you are away from your desk
Read OpsMate patrol alerts in a private Telegram chat, gather evidence with AI assistance, and review proposed changes before acting.
SSH from your phone is painful: troubleshoot your server from Telegram instead
Describe the problem in one message and let AI run the checks over SSH. Every action is sorted into one of three risk tiers. Low-risk actions (such as a confident service restart or log rotation) run automatically. Medium-risk actions (such as changing config or recreating a container) are sent to you for approval first, and run automatically if no one responds within 30 minutes. High-risk actions (database schema, kernel parameter, network and firewall changes) only raise an alert and are never executed. When the system isn't sure, it treats the action as the next tier up. Commands that fail the safety check are blocked and never run. Low-risk fixes run automatically by default, and every step is logged. Plus when to go back to a computer.
Docker container exits immediately? Check why it exited from the exit code
Confirm the exit state, look up what 0, 1, 125–127, 137, 139 and 143 usually mean and what they don't prove, then find the first error in the logs.
Exit code 137 and OOMKilled: was your container out of memory, or killed by something else?
Exit code 137 means SIGKILL. Find out who sent it (the kernel OOM killer, Docker or something else on the host) with OOMKilled, docker events and the kernel log, then choose a next step.
Docker container keeps restarting? Break the restart loop
Confirm the restart loop, then check the restart policy and backoff, healthchecks, dependencies and resource limits.
Container is up but the site shows 502? Start with Nginx 502 Bad Gateway: find the cause from the error.log line.
Memory alert in Telegram? Server memory 88%: is it a problem, and what to check
Server memory at 88%? Look at available memory first: free -h, swap activity, PSI and OOM logs, then see what OpsMate recorded in a real test environment.
Docker logs filling your disk: diagnose before cleaning up
When df shows a full disk, separate capacity from inodes, confirm json-file log growth with docker inspect, then set max-size/max-file in a maintenance window.
Linux disk usage spike? Find what filled the disk in 3 steps
Disk usage spiked or disk full on Linux? 3 checks: df -h vs df -i, du on the full filesystem, then logs, app data or deleted files still held open.
Plaintext secrets on your server or in your repo? A 3-step self-check
Passwords and tokens hide in .env files, shell history, docker inspect, crontab and Git history. Find them with read-only checks, rotate before removing, and redact logs before sending them to AI.
Nginx 502 Bad Gateway: find the upstream error and fix it on Ubuntu
502 Bad Gateway from nginx means the upstream failed. Match your error.log line (connection refused, prematurely closed, invalid header) and fix it on Ubuntu.
A small-team VPS monitoring checklist: six things to check after launch
Without a dedicated ops hire, cover external uptime, resources, services, logs, backups, and who gets paged—plus a read-only baseline and how OpsMate patrols fit in.
Was my Linux server hacked? Read-only checks for suspicious logins and processes
Tell login attempts from successful logins, check processes and persistence, and preserve evidence. No verdicts; escalate when in doubt.
Contractor or ex-employee left? How to revoke their server access
List what they could reach, find who can still log in, add your own key before removing theirs, lock accounts with a backup and a way back, then replace the secrets they saw and check for leftover jobs.
Inherited a server: what to check first when you have no ops hire
Inherited a server: what to check first — inventory services, ports, backups and certs on one page, then set a weekly check and an escalation path.
If the site went down overnight, or you see a suspicious SSH login, follow that guide before changing the server.
Need help interpreting the evidence?
OpsMate (itops.sh) puts your SSH terminal and AI on one page, and you review the evidence. Each time you ask the AI for help, recent terminal output is sent to the cloud AI along with your message, so remove sensitive information first.
Start free Desktop with local credentials