6/5/2026
1C Running Slow: Five Common Causes and How to Find Them
"Buy a bigger server" isn’t a diagnosis — it’s a guess. Here’s what actually slows 1C down most often, and how to check without overspending.
The phrase “1C is slow” has an annoying property: it can hide a dozen genuinely different technical causes, and it usually gets treated with a guess — most often a new server. Sometimes that actually helps. More often it doesn’t, because the problem was never the hardware.
| Symptom | Likely cause |
|---|---|
| Slow for everyone, all the time, even Monday morning | Server resource shortage — RAM or disk subsystem |
| Slow only when generating specific reports | Unoptimised code in the configuration or missing indexes |
| Slow only for remote employees | Network latency, not 1C itself |
| Gets worse over time, only a restart helps | Database isn’t maintained — needs reindexing and updated statistics |
| Freezes when several people work at once | Lock contention at the database write level |
1. The server is running at its resource limit
Insufficient RAM or slow disks — especially HDDs instead of SSDs under the database — is the most common cause of slowdown as the database and user count grow. Checking it is simple: monitor load during peak hours, not a one-off measurement taken when everything’s already quiet and fine.
2. The database isn’t maintained regularly
MSSQL and file-based 1C databases need regular reindexing and updated statistics. Without it, query performance degrades so gradually that staff get used to it and stop complaining, chalking it up to “that’s just how 1C is.” By the time the slowdown is noticeable even to people who’ve adapted, the database is usually badly fragmented.
3. Network latency over terminal or RDP sessions
If users work with 1C remotely over an unstable connection, it isn’t 1C that’s slow — it’s the network, and 1C just delivers that feeling to the user. The fix is technical: a terminal server closer to the database, or optimising the connection itself, not fiddling with 1C settings that have nothing to do with it.
4. Unoptimised code in customisations
Reports and processing routines written without performance in mind are a common cause of freezes tied to specific operations rather than the system as a whole. A hardware upgrade won’t fix this — profiling the slow operation and targeted query optimisation will.
5. Lock contention under concurrent use
With many simultaneous users, operations can start blocking each other at the database write level — in which case it isn’t the server or the network that’s slow, it’s the queue. The fix is switching to managed locks and reviewing how concurrent document handling actually works.
Before you buy anything
Diagnostics start with monitoring, not intuition. Without data on server load, slow-query statistics, and lock logs, the cause of a slowdown can only be guessed at — and a wrong guess means spent budget and the exact same slow 1C a month later.