The failure modes most ERPNext teams eventually face
ERPNext is powerful. Most production pain comes from operating it without visibility, control, safe upgrades, and proven recovery. This page describes the problems plainly - and how we turn them into predictable operations.
If downtime is acceptable, logs are “good enough,” or upgrades are rare and rushed - this probably isn’t for you.
Common problems
What goes wrong in real production
Each section includes symptoms, root causes, typical (weak) responses, and what operational control looks like.
Failure mode
Background jobs fail silently
Symptoms
- Emails stop sending, reports stop generating, and automations quietly stall.
- Integrations get stuck mid-flow: partial sync, duplicates, or missing updates.
- Failures are discovered hours later-when users complain.
Root causes
- RQ/Redis queues with limited native observability.
- Failures live in logs; the UI doesn’t surface evidence or trends.
- Retries are ad-hoc; operators lack safe actions (retry/requeue/cancel) with guardrails.
What most teams do
- Restart workers/Redis and hope the issue disappears.
- Manually re-run jobs without understanding idempotency risks.
- Search logs reactively, after business impact has already happened.
What we do
- Expose queue depth, worker health, stuck jobs, and failure hotspots.
- Group failures by method and recurrence; preserve evidence.
- Provide safe actions: retry, requeue, cancel-plus audit trails and alerts.
Failure mode
Upgrade fear (teams delay upgrades for years)
Symptoms
- Sites stay on old versions because upgrades feel like gambling.
- Upgrades happen under pressure and break customizations.
- Every upgrade becomes a fire drill instead of a planned operation.
Root causes
- Customization rot: scripts and reports reference fields/APIs that change over time.
- Third-party apps pin versions or use private/internal APIs.
- Lack of preflight checks: environment gaps (DB, Redis, Node/Python), patches, or disk headroom.
What most teams do
- Skip upgrades until forced by security or major failures.
- Upgrade directly in production or with weak staging parity.
- Fix breakages after the fact with emergency patches.
What we do
- Quantify risk before upgrade: evidence + severity + fix list.
- Run preflight checks and generate an upgrade runbook with verification steps and rollback planning.
- Turn upgrades into repeatable operations, not heroic interventions.
Failure mode
Data integrity drift (stock & accounting stop agreeing)
Symptoms
- Stock levels don’t match reality; negative stock surprises appear.
- Ledgers don’t reconcile cleanly; audits become painful.
- Numbers look “almost right,” until they aren’t.
Root causes
- Partial transactions from failed background jobs or interrupted flows.
- Integration drift: mismatched item mappings, duplicate documents, or missing postings.
- Manual SQL “fixes” that bypass business logic and create hidden inconsistencies.
What most teams do
- Patch symptoms: adjust stock manually, reverse entries, run ad-hoc scripts.
- Blame users for “wrong processes,” while issues are systemic.
- Avoid changing anything out of fear of making drift worse.
What we do
- Detect drift patterns early using ERPNext-aware signals and evidence trails.
- Instrument workflows so every critical operation has traceability.
- Build reconciliation workflows for integrations to prevent repeated drift.
Failure mode
Performance bottlenecks are invisible
Symptoms
- Users complain ERPNext is slow-sporadically and unpredictably.
- CPU graphs look fine, but timeouts happen.
- Queue backlogs grow, but nobody correlates causes.
Root causes
- Worker starvation and queue saturation aren’t visible in generic monitoring.
- Lock contention and slow queries are disconnected from user symptoms.
- No correlation between requests, background jobs, and infrastructure limits.
What most teams do
- Increase server size without understanding bottlenecks.
- Disable features or reduce usage as a workaround.
- Treat performance as a mystery instead of an engineering problem.
What we do
- Surface ERPNext-aware metrics: queues, workers, locks, scheduler health, and latency patterns.
- Add practical dashboards for operators: what to fix first, what to watch, and when to scale.
- Use evidence to reduce guesswork and stop over-provisioning.
Failure mode
Backups exist… but restores are untested
Symptoms
- Teams believe they are safe because backups run.
- During a real incident, restore takes hours-or fails.
- Recovery becomes guesswork under pressure.
Root causes
- Cron-based backups without restore verification.
- No audit trail, no retention discipline, no operator UI.
- No clear RPO/RTO expectations or tested runbooks.
What most teams do
- Keep backups on the same server (single point of failure).
- Test restore “someday.”
- Scramble during outages and learn the hard way.
What we do
- Automate backups and verify restores routinely.
- Provide a simple interface to browse, download, restore, and prove recovery readiness.
- Tie recovery to runbooks so incidents are repeatable, not improvised.
Failure mode
Integrations are brittle (especially under failure)
Symptoms
- Duplicate records, missed updates, and inconsistent states across systems.
- Stock drift between ERPNext and commerce channels.
- Webhooks arrive out of order, repeat, or partially fail.
Root causes
- Lack of idempotency and deterministic conflict handling.
- No replay/retry strategy with evidence and auditability.
- No reconciliation workflows to correct drift safely.
What most teams do
- Rely on manual fixes and ad-hoc scripts.
- Disable syncing when it breaks and accept “data lag.”
- Treat integration failures as unavoidable.
What we do
- Build enterprise-grade sync: idempotency, conflict handling, replay, retries, and audit trails.
- Instrument every integration event so you can explain what happened.
- Provide operational controls to recover from failure without corruption.
Failure mode
Operational knowledge disappears when people leave
Symptoms
- Only one person knows how things work.
- Onboarding is slow; incident response is chaotic.
- Documentation exists but is outdated, scattered, and untrusted.
Root causes
- Docs live outside systems and don’t evolve with production changes.
- No ownership model or review cadence for SOPs/runbooks.
- No search-first operational knowledge base tied to real workflows.
What most teams do
- Store docs in random folders or chats.
- Rely on ‘ask John’ as the operating model.
- Write docs once, then never update them.
What we do
- Treat operational knowledge as infrastructure: owned, searchable, current, and linked to operations.
- Create runbooks for upgrades, recovery, queues, and integrations.
- Turn incident response into repeatable procedures.
Next step
If ERPNext is mission-critical, operate it like infrastructure.
We’ll review your environment (queues, upgrades, backups, performance, and integrations) and produce a clear plan to improve reliability and operational control.
Note: This page intentionally prioritizes operational truth over marketing language.