Why ERPNext error tracking with Sentry matters for finance and operations teams
Sentry integration gives an ERPNext team grouped, searchable reports of server and browser errors, so a failing journal entry or stock posting is seen by the team before a user files a complaint. Teams need it when errors today surface only as user tickets or as individual rows in the Error Log inside the desk, where the same failure can appear dozens of times with no clear pattern. Finance and operations teams feel this most during month-end close, when a repeated failure in a posting or report blocks work and the team needs to know how often it happens, for which sites and since which change.
ERPNext produces two kinds of error that need different handling. Server-side errors are Python exceptions raised in the Frappe Framework, in controllers, scheduled jobs, background workers or server scripts, and they show up in server logs and the Error Log. Desk JavaScript errors happen in the browser while a user works in the desk, such as a form that fails to render or a client script that throws, and they never reach the server unless something reports them. A useful Sentry setup has to capture both, and it has to tie each event to the site and bench it came from.
Sentry is a separate system that your team must choose, host and operate. You can use the hosted Sentry service or a self-hosted Sentry instance, and either way you own the decisions on retention, access to event data and who can see personal data in stack traces. Before enabling anything, confirm with your security and privacy leads where error data may be stored, which users may read it and what a scrubbing policy must remove. Those answers shape the DSN, the site opt-in and the privacy settings covered later in this page.
Sentry deployment and configuration options and when each fits
This table compares the hosting, DSN and data-handling choices for sending ERPNext errors to Sentry, and when each one suits a regulated organization. Read each row as a decision to settle with your security and privacy teams before the first bench is connected. Every option must be checked against the Sentry and Frappe documentation for the versions you run.
| Option | What it means for ERPNext | When it fits a regulated organization |
|---|---|---|
| Hosted Sentry | Errors leave your network for a vendor-operated service. Setup is fastest and no Sentry servers are patched by your team. | Fits when your data processing agreement, data residency terms and sub-processor list have been reviewed and approved for stack traces that may include site and user context. |
| Self-hosted Sentry | Sentry runs in infrastructure you control, so event payloads stay inside your boundary. Your team owns upgrades, storage, backups and sizing. | Fits when error data must remain in controlled systems or your policy restricts external telemetry, and you can staff the ongoing operation. |
| One DSN per bench | Each bench has its own project or key, so errors can be separated by environment, business unit or release train. More projects mean more to govern. | Fits when different benches hold data under different controls, such as production finance and a test bench, and access to error data must be scoped per system. |
| Shared project across benches | One DSN covers several benches and events are told apart by tags or environment names. Fewer projects to administer. | Fits when all benches share one control set and one team owns triage. Confirm that tags cannot be used to route events to people without access to the underlying site. |
| Site opt-in | Error reporting is enabled for selected sites only, through site configuration. Unlisted sites send nothing to Sentry. | Fits when a change board must approve each site before telemetry starts, and when test sites holding copies of personal data should stay silent. |
| Tracing sample rate | Controls the share of requests and jobs that record performance spans. Higher rates add event volume and can capture more database detail. | Fits a low, deliberate rate in production for regulated workloads, with a documented reason for the value. Confirm the setting name and default for your version. |
| Profiling sample rate | Controls how many transactions include profiling data such as call stacks. Profiles can expose code paths and variable context. | Usually fits only where a named engineering owner needs it for slow-page investigations and the profile data is covered by your retention rules. |
| Privacy and data scrubbing | Settings decide whether user identifiers, request bodies, headers and personal data fields are sent. Defaults should be checked, not assumed. | Required in most regulated settings. Confirm which fields are scrubbed or excluded for your Sentry SDK and Frappe version, and test with a sample event before enabling production. |
Setting up Sentry for an ERPNext bench, step by step
This sequence takes one bench from no error reporting to a verified, privacy-reviewed Sentry setup. Each step ends with a check so the platform owner can confirm that events arrive in the right project before tracing is switched on.
Decide the Sentry project and DSN per bench
The platform owner, with the security or engineering lead, decides which Sentry project receives events from each bench, usually one project per bench and environment. A staging error should never land in the production queue. Record which environment each DSN belongs to, who can read it, and who approves changes to it. This step is done when the mapping is written down and approved. Check: every bench in the inventory has exactly one named project and one accountable owner.
Create the Sentry project and client key
An engineer creates the project in the Sentry instance your organization uses, whether hosted or self-hosted, and selects the platform that matches the SDK documentation for your Frappe version. Copy the DSN from the project's client key settings and store it as configuration in your secrets tooling, not in tickets or chat. Check: the DSN is visible in the project settings, and if the console offers a setup test, it reports the project as waiting for its first event.
Configure bench and site settings for opt-in
The engineer adds the DSN and reporting settings to the bench configuration on staging only, and leaves production sites without reporting until the earlier checks pass. Confirm the exact configuration key names against the Frappe documentation for your version, because this page does not list them. Each site should have its own opt-in, so a site that has not been approved stays silent. Check: reading the configuration back on staging shows the settings, and production sites show no change.
Enable server and desk JavaScript reporting
The engineer turns on server-side reporting so Python exceptions from web requests, background jobs and scheduled work are captured, then turns on desk JavaScript reporting so errors in browser-side forms and pages are sent. Restart the bench services that load the configuration, including workers and the scheduler. Check: trigger a deliberate error on a non-production desk page and confirm it appears in Sentry with the site name and environment attached.
Verify a test error arrives correctly
The engineer produces a controlled test error on staging, then confirms it reaches the correct project and environment and carries a stack trace. Open the event and read the full payload, including request data, breadcrumbs and user fields. Confirm that no document contents, customer names, email addresses, session data or tokens appear in them. Check: the test event sits in the intended project only, and the payload review is recorded with the bench's entry in the mapping.
Confirm privacy settings before enabling tracing
Before performance tracing or profiling is switched on, the data protection owner reviews what those features add, since request URLs, database spans and user context can carry business data. The engineer sets sampling rates conservatively, turns off capture of request bodies and client IP addresses where the options allow, and applies scrubbing rules for sensitive fields. Enable tracing on staging first. Check: a sampled transaction on staging shows no record identifiers or personal data in its span descriptions, and the sign-off is filed before production is changed.
How Sentry brokers ERPNext errors per bench and per site
The DSN is scoped to the bench, but reporting can be controlled per site. A bench is one set of installed apps and one Python environment, so the Sentry client it initializes is shared by every site on that bench. Sites do not get separate DSNs by default. To split errors, set the destination at bench level and use a site-level setting to decide whether a given site reports at all. Illustrative: one bench serves erp-prod.example.com and erp-sandbox.example.com. Production reports to the ERP project, while the sandbox stays silent because its site-level opt-in is off. Before you rely on this, confirm in your Frappe version which keys are read from the common bench configuration, which from each site's site_config.json, and whether a site value overrides the bench value.
Once the client is initialized, the framework forwards server-side exceptions and desk JavaScript errors to it. Server errors come from Python request and background job handling, while desk errors come from the browser session of a logged-in user. The two paths depend on the framework release, so confirm that your version includes the Sentry hook for each one and whether desk JavaScript capture is enabled by default. Check the Frappe supported versions page first: version 14 reached end of life on January 31, 2026, version 15 is planned for support until the end of 2027, and version 16 until the end of 2029. Then trigger a deliberate exception on a staging site and confirm that one event arrives in the correct project with the expected environment label.
Privacy and security settings to decide before enabling Sentry
Sentry receives more than a stack trace: request context, breadcrumbs and user details can carry personal data or secrets from an ERP. Each card below is a decision to settle with your security or privacy team before the first event leaves the bench.
Personal data in error payloads
ERPNext errors often carry request context such as customer names, supplier details, employee identifiers or addresses taken from the document being saved. Before enabling Sentry, decide which fields may leave the server and whether event scrubbing or data filtering rules will be configured in Sentry. Confirm with your privacy team whether an error payload counts as a processing activity and what your records of processing must list.
Credentials and tokens in breadcrumbs
Breadcrumbs record recent actions, including URLs, form inputs and API calls, which can include session cookies, API keys sent by integrations or tokens in query strings. Ask your security team which header and parameter names must be masked and test with a staged site that a deliberately fake token does not appear in any event. Keep integration credentials out of logs and request bodies wherever possible.
Data residency of hosted Sentry
If you use the hosted Sentry service, events and their contents are stored in the region that your Sentry organization uses. Confirm with your legal and privacy team which regions are available to your contract, where the data will be processed and which subprocessors are involved. If residency rules are strict, self-hosting Sentry inside your own infrastructure may be the simpler answer, but that moves the operating burden to your team.
Access control on the Sentry project
Anyone with access to the Sentry project can read stack traces, request context and user data attached to events. Decide which roles may view events, who may change data scrubbing rules and who may create or rotate DSNs. Review membership whenever staff change roles, and confirm with your security team that single sign-on and multi-factor authentication apply to Sentry users.
Retention of events
Events kept in Sentry remain accessible until the retention period ends, and their contents may be copied into exported data or support requests. Agree a retention period with your privacy team that matches the purpose of debugging, and confirm how long deleted events persist in backups for the hosting option you choose. Check whether attachments and profiles have separate retention settings.
DSNs kept out of shared repositories
A Sentry DSN identifies the project and allows events to be submitted to it, so it should be treated as configuration rather than public text. Store each bench's DSN in site configuration or a secrets manager, never in a Git repository, custom app or exported customization that others can read. Confirm with your security team how DSNs are rotated after a staff departure or a repository exposure.
Questions teams ask before setting up ERPNext error tracking
What does it cost to send ERPNext errors to Sentry, and who pays for it?
The cost has three parts: the work to configure the integration, the Sentry subscription or self-hosting infrastructure, and the time your team spends reviewing events. Sentry's hosted plans are billed by the vendor and their pricing is set on Sentry's own site, so confirm current tiers directly with Sentry before budgeting. Self-hosting moves the cost to your servers, storage and staff time for upgrades and backups. DeployOpen does not publish prices. Ask for a quote that lists the implementation as a fixed scope, the Sentry plan or hosting you will use, and whether ongoing tuning is included or offered as a retainer.
How long does ERPNext error tracking setup take, and what drives the effort?
The effort depends on how many benches and sites you run, whether each one needs its own DSN, how many environments must be covered, and how much privacy review is required before events leave your network. A single bench with one production site is a small job. Multi-bench estates, staging copies and separate desk JavaScript and server configurations add steps for each environment. Ask for a scope that names the benches, sites, environments and Sentry deployment model, and a timeline tied to those items rather than a generic duration.
What must our team provide before the work can start?
Three things are needed early. First, a named owner for each DSN, usually one project per bench or environment, so you control rotation and access. Second, Sentry access for the people who will triage events, plus an admin who can create projects and manage members. Third, a privacy sign-off that defines which request data, user identifiers and stack variables may be sent, and whether session replay or profiling is allowed. Without that sign-off, the safest configuration is to keep the feature off until your data protection or security lead approves it.
Can our own team set up ERPNext error tracking without a partner?
Yes, if your team already runs bench commands, edits site configuration and manages secrets. The core steps are creating a Sentry project, placing the DSN in the right site configuration, enabling the opt-in per site and checking that test errors arrive. The harder parts are deciding what to send, setting sampling and privacy options, and keeping the DSN out of shared repositories. Confirm the exact configuration keys against the ERPNext and Frappe documentation for your version, since they change between releases. A partner is most useful when you want those decisions made and documented in one pass.
Does self-hosted Sentry add much operational load?
Yes. Self-hosting Sentry means running its services, databases, event storage and upgrades on infrastructure you control. You take on capacity planning for event volume, backups, certificate management, patching and version upgrades, and you must keep the Sentry server reachable from every bench. Ask any provider to state which Sentry version they will deploy, how upgrades are scheduled, how data is backed up and who is on call when event ingestion stops. If your team cannot staff that work, the hosted Sentry service may be the lower-risk choice.
How does Sentry relate to the Error Log in the ERPNext desk?
The Error Log in the desk records errors that ERPNext captures on the server, and it stays useful as a local record that does not depend on any external service. Sentry adds centralized grouping, alerting, release tracking and a view of JavaScript errors that happen in the browser. Many teams keep both: the Error Log for quick in-app review and Sentry for triage across benches. Confirm during planning which errors each path captures, so that alerts and retention rules do not conflict with your incident process.
What privacy settings should we decide before enabling tracing or profiling?
Decide these before any event is sent. Tracing and profiling record timing and request details that can include document names, user identifiers and query context, so they carry more personal and business data than a plain error message. Define the sampling rate, which environments may send traces, whether user identifiers are attached, how long events are retained in Sentry and who can view them. Document the decision as a short written standard that your security and privacy leads approve. Ask your provider to show how each setting maps to that standard in the configuration.
Running Sentry alongside ERPNext logs and on-call duties
Sentry should be treated as a second lens on ERPNext failures, not a replacement for the logs you already have. The ERPNext Error Log in the desk still records errors with the user and request context that operations staff use to answer "what did this user just do?". Server log files under the bench still hold the stack output from gunicorn, workers and the scheduler, and worker error logs capture failed background jobs that never reached a browser. Sentry adds grouping, release tagging and alerting across these sources. Before go-live, document which system is the first place each team looks for each class of failure, so an on-call engineer does not search three places for one problem.
Decide alert routing before the first real incident. Send new issues from the server project to the team that owns the bench, and send desk JavaScript issues to whoever owns customizations, since client scripts often cause them. Route only new or regressed issues to a paging channel and send the rest to a daily digest. Name one triage owner per week who classifies each new issue as a bug, a customization defect, a third-party failure such as a mail provider timeout, or noise. Confirm in your Sentry plan how alert rules, teams and notification integrations are configured and whether they can be managed as code, since that affects how easily the rules survive staff changes.
Noise reduction is a configuration task you repeat, not a one-off. Use Sentry's grouping and fingerprint rules to merge duplicates that differ only by document name or ID, and filter expected errors such as validation messages that users trigger on purpose. Review the ignored list monthly so a real defect is not hidden by an old filter. After each ERPNext upgrade, and after each batch of custom app or client script changes, review new issues for the first two weeks and reset alert thresholds if the volume shifts. Your upgrade plan should name this review as a step, with an owner and a sign-off that the error volume matches the pre-upgrade baseline.
How DeployOpen scopes and supports ERPNext error tracking
DeployOpen plans and implements ERPNext error tracking with Sentry inside your own infrastructure, whether you use Sentry's hosted service or a self-hosted instance. The work starts with a written scope that names each bench, site and error source, then moves through a tested build, documented handover and optional ongoing support.
How we scope
- Inventory every bench and site that should report errors, and the environments each one belongs to.
- Agree in writing whether Sentry is hosted or self-hosted, and who owns the DSN and project settings.
- Record the privacy rules for user data, request bodies and tracing before any event leaves your network.
How we build
- Configure the DSN per bench and enable reporting only on the sites that opted in.
- Set tracing and profiling sample rates to values agreed in the scope, then test them against a staging site.
- Verify that server and desk JavaScript errors arrive in Sentry with the expected context and no sensitive fields.
How we hand over
- Deliver a runbook covering DSN rotation, opt-in steps for new sites and how to disable reporting quickly.
- Document the privacy and sampling settings, with the reason each one was chosen and who approved it.
- Walk your platform and security teams through alert triage so they can act on Sentry events independently.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, including checks after ERPNext upgrades.
- Ask your DeployOpen contact to confirm which Sentry and ERPNext versions the quote covers before work begins.
