NineLabNineLab.ru
CasesPrices
Contacts
December 15, 2025Evgeny · Technical Director

5 Signs Your Website Is About to Crash


The Titanic didn't sink instantly. First came the hit, then water in the holds, and only then — disaster. Your website is the same. It "screams" for help long before it crashes. Do you know how to read these signals?

Key takeaway. Sites do not fall out of nowhere: first TTFB, a full DB pool, swap, rising 5xx, or silent logs. Prometheus/Zabbix alerts should fire before angry customer messages.

Checklist: Symptoms of Imminent Death

🔴 CRITICAL WARNINGS:
[WARN] TTFB rose to 800ms (avg: 120ms)
[WARN] DB Connections: 98/100 used
[ERR] Out of Memory: Kill process 'postgres'
[ERR] 502 Bad Gateway (Rate > 2%)

*If you see this in logs — call NineLab.

1. TTFB Growth (Time to First Byte)

If the server thinks longer than 200ms before giving the first byte — this is the first bell. It means code or database is already working at the limit.

2. "Too many connections" in DB

Every SQL request requires a connection. If the pool is full, new users just get an error. This is a classic scaling problem.

3. Disk Swap

The scariest sign. When RAM ends, the server starts using HDD/SSD as memory. Disk is 100,000 times slower than RAM. The site turns into a pumpkin instantly.

4. Growth of 5xx Errors

One 500 error per day is an accident. Ten errors per hour is a pattern. 1% errors of total traffic is a fire.

5. Log Silence

Sounds strange, but if logs suddenly stopped writing, maybe you just ran out of disk space. This is "silent death".

Advice: Configure alerts in Zabbix or Prometheus. Learn about problems before your users write an angry tweet.

Next steps

Validate before traffic peaks: load testing, performance audit, pricing.

Signs your site is about to fall — FAQ

TTFB climbing past ~200 ms, a nearly full DB connection pool, swap instead of RAM, 5xx around 1% of traffic, and sudden log silence (often a full disk). These show up before a 503, not after you are already down.

If the server thinks longer than ~200 ms before the first byte, and your baseline is 100–120 ms, code or the database is already at the limit. 800 ms TTFB is not "a bit slow" — it is a queue before failure.

When RAM is gone the disk becomes "memory" and is orders of magnitude slower. The site degrades in a jump: timeouts, 502s, postgres killed by OOM.

Do not wait for an ad peak: alerts in Zabbix/Prometheus, check the DB pool, disk and RAM, then an audit or load test. Ten 500s an hour is a pattern, not a fluke.

Want to apply this in practice?

Tell us about your system — we’ll propose a work plan and the metrics worth fixing in an SLA/SLO.

All posts: Audit & Testing

Audit & TestingAugust 20, 2026
AI Agent Development for Business: 2–4 Week Pilot, Not a Demo Bot

AI agents for business: how they differ from chatbots and RAG widgets, what a 2–4 week pilot includes, on-prem, CRM/ERP/API integrations, orchestration and KPIs. Checklist before you buy.

Read Article
Audit & TestingJune 20, 2026
1C and ERP Integration with a Web App: What to Put in the Spec Before Signing

How to connect 1C/ERP to a portal, CRM, or request system without double entry: master data, REST/OData, sync frequency, conflict rules, and integration budget ranges for CEOs and CTOs.

Read Article
Audit & TestingJune 20, 2026
IT Projects for Leadership: 10 Questions Before You Sign

A checklist for CEOs, CFOs and boards: measurable outcomes, business owner, IP, SLA, contract exit and vendor red flags — without microservices jargon.

Read Article
Audit & TestingJune 19, 2026
Developer Outstaffing: Senior Squad vs a "300-Person Farm"

How to choose outstaffing: rates, time to onboard, NDAs, velocity transparency, and when a boutique team beats a large integrator.

Read Article