> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Platform Error Spike or Extension Conflict, OpenCart > Real-time alert that catches a self-hosted OpenCart failure or an extension conflict the moment the error log starts climbing. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Real-time alert that catches a self-hosted platform failure or an OCMOD / vQmod extension conflict the moment the error log starts climbing, before customers hit a white screen. ## At a glance > OpenCart is self-hosted, open-source PHP, which means platform failures are *your* failures: a broken extension, a botched modification, a PHP version bump, a corrupted modification cache. This alert watches the OpenCart system error log volume and the OCMOD / vQmod modification state, and fires when error volume jumps beyond two standard deviations of its baseline, or when a new extension conflict is detected. On a managed SaaS platform this category barely exists; on OpenCart it is the single most important early-warning signal you have. | | | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it watches** | The OpenCart system error log (written by the framework under System → Maintenance → Error Logs) and the modification (OCMOD / vQmod) conflict state. | | **Error baseline** | A rolling baseline of normal error-log write volume. A few PHP notices per hour is normal background noise; a sudden multiple of that is not. | | **Conflict detection** | OpenCart modifications patch core files via OCMOD (built in) or vQmod. When two extensions try to patch the same code, or a refresh fails, OpenCart flags it. This alert surfaces a newly detected conflict. | | **Refunds / orders / currency** | Not applicable. This is an infrastructure-health alert, not a money or order metric. | | **Multi-store** | A single OpenCart install shares one codebase and one error log across all `store_id` storefronts. An extension conflict affects every store at once. | | **Time window** | RT (continuous evaluation against the error-log baseline) | | **Alert trigger** | Error-log volume `> 2 sigma` above baseline **OR** a new extension conflict detected | | **Roles** | owner, operations | ## Calculation Calculated automatically from your OpenCart data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A Malaysian electronics store on OpenCart 4.x running about a dozen extensions: a payment gateway, a shipping-rate calculator, a product-feed exporter, and several front-end tweaks installed via OCMOD. The error log normally records around 3 to 6 PHP notices per hour, mostly deprecation warnings. The store owner installs a new "related products" extension on the morning of 14 Mar 26. | Time (14 Mar 26) | Error-log writes / hour | Baseline | State | | ---------------- | ----------------------- | -------- | -------------------------------------------------------- | | 09:00 | 4 | \~5 | Normal | | 10:00 | 5 | \~5 | Normal | | 10:20 | new OCMOD applied | - | "Related products" installed and modifications refreshed | | 11:00 | 142 | \~5 | **ALERT FIRES** (error spike + new conflict) | | 12:00 | 138 | \~5 | Still elevated, product pages throwing fatals | | 13:30 | 6 | \~5 | Recovered after extension disabled | What's interesting here: 1. **The new extension patched a file another extension already owned.** The "related products" OCMOD targeted the same product-page template the existing review extension had already modified. After the modification refresh, the merged file was malformed and PHP threw a fatal error on every product page load. The error log went from 5 writes an hour to 142. 2. **Two signals fired together.** The alert payload showed both an error-volume spike *and* a newly detected modification conflict. That combination points straight at the OCMOD layer rather than at, say, a database outage or a memory limit. 3. **Customers were hitting white screens before the owner knew.** A fatal on the product page means the storefront product pages were broken for roughly two and a half hours. Without the alert, the first signal would have been a drop in orders or a customer email; the alert caught it in minutes. 4. **The fix was a rollback, not a code change.** Disabling the offending extension and refreshing modifications under Extensions → Modifications cleared the conflict and the error volume fell back to baseline. The merchant could then re-test the extension in a staging copy rather than on the live store. 5. **The baseline absorbed normal noise.** The store's steady trickle of deprecation notices never came close to the 2-sigma line, so the alert stayed silent until something genuinely abnormal happened. ## Sibling cards merchants should reference together | Card | Why pair it with Platform Error Spike or Extension Conflict | | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Error Log Volume (24h)](/nerve-centre/kpi-cards/opencart/error-log-volume-24h) | The trend view of the same error log. This alert catches the spike; that card shows the 24-hour shape so you can see whether it is settling or sustained. | | [Extension / Modification Conflicts](/nerve-centre/kpi-cards/opencart/extension-modification-conflicts) | The detailed conflict picture. When this alert fires on a conflict, that card tells you which modifications are colliding. | | [Installed Extensions / Modules](/nerve-centre/kpi-cards/opencart/installed-extensions-modules) | The inventory of what is installed. A conflict almost always traces back to a recent change in this list. | | [OpenCart Version Status](/nerve-centre/kpi-cards/opencart/opencart-version-status) | PHP-version and core-version mismatches are a common error-spike cause. If you just upgraded, check here first. | | [Order Processing Backlog](/nerve-centre/kpi-cards/opencart/order-processing-backlog) | A broken payment or shipping extension shows up as both an error spike here and a stalled backlog there. | | [Revenue at Risk (live)](/nerve-centre/kpi-cards/opencart/revenue-at-risk-live) | Quantifies the commercial cost while the storefront is degraded. | ## Reconciling against OpenCart **Where to look in the OpenCart admin:** System → Maintenance → Error Logs shows the raw PHP error log the framework writes. This is the primary source this alert watches. Extensions → Modifications lists every OCMOD / vQmod modification and flags conflicts; the "Refresh" action here is what re-applies modifications after an install or removal. Extensions → Extensions (or Extensions → Installer for OpenCart 4.x) shows what is installed and enabled. OpenCart admin views that *look* like the same thing but aren't: * **The PHP server error log** (in your hosting control panel or `/var/log`) is a superset; it captures errors from before OpenCart even bootstraps, which the in-app log cannot see. * **The Dashboard** shows no error information at all; a healthy-looking dashboard can sit on top of a broken product page. * **Extensions → Modifications without a recent Refresh** can show a stale conflict state; always refresh before trusting it. **Why our number may legitimately differ from the OpenCart admin:** | Reason | Direction of divergence | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | | **Timezone.** Error-log timestamps follow the server timezone; Vortex IQ evaluates the baseline in UTC by default. Spike windows can appear shifted by the offset. | Cosmetic timing shift | | **Multi-store.** One codebase, one error log, all `store_id` storefronts. A conflict here affects every store; the admin does not separate errors per store. | Not separable | | **Log rotation / clearing.** If you clear the error log under System → Maintenance, the admin shows an empty file while Vortex IQ still holds the historical baseline. | Admin lower than the card's history | | **Server-level errors.** Fatals that prevent OpenCart from booting may never reach the in-app log; they land only in the server log. | Card may under-count truly catastrophic failures | | **API / DB sync lag.** Vortex IQ reads on a sync cadence; the most recent minute of errors may not yet be reflected. | Self-resolves at next sync | **Cross-connector note:** an error spike that coincides with a website-performance or uptime drop on a connected monitoring tool usually points at a server-resource problem (memory, CPU, disk) rather than a single extension. An error spike with healthy server metrics points at the code, that is, an extension or modification.
Same-metric documentation cross-reference (for agencies running multiple platforms) This alert is OpenCart-distinctive because OpenCart is self-hosted. Managed SaaS platforms surface a thinner version of platform health. These links help agencies running multi-platform client books find the nearest equivalent. * [`shopify.platform_error_spike`](/nerve-centre/kpi-cards/shopify/platform-error-spike) (planned) * [`bigcommerce.platform_error_spike`](/nerve-centre/kpi-cards/bigcommerce/platform-error-spike) (planned)
## Known limitations / merchant FAQs **Why is this card OpenCart-specific in a way it isn't for Shopify?** Because OpenCart is self-hosted open-source PHP. You own the server, the PHP version, and every extension. On a managed SaaS platform the vendor absorbs most platform failures; on OpenCart they surface in *your* error log and they are *your* responsibility. This alert is your first line of defence. **What is OCMOD and why does it cause conflicts?** OCMOD is OpenCart's built-in modification system. Instead of editing core files directly, extensions ship XML instructions that patch core files at runtime. vQmod is an older third-party equivalent. Conflicts happen when two modifications try to patch the same line of the same file, or when a refresh produces a malformed merged file. The result is often a fatal error on a specific page. **The alert fired but the error log looks empty now, what happened?** The most likely cause is that the error log was cleared (manually or by rotation) after the spike. The alert holds the historical baseline even after the file is emptied. Check Extensions → Modifications for a lingering conflict, and your server-level log for anything the in-app log missed. **A 2-sigma trigger sounds noisy, will it fire on routine warnings?** No. A steady trickle of PHP notices and deprecation warnings is the baseline the 2-sigma line sits above. The alert needs a genuine multiple of normal volume, or a brand-new conflict, to fire. Routine noise stays under the line. **I upgraded PHP and now the alert keeps firing, why?** A PHP version bump frequently breaks older extensions that used removed or deprecated functions. The flood of new deprecation or fatal errors pushes the log past the baseline. Check [OpenCart Version Status](/nerve-centre/kpi-cards/opencart/opencart-version-status) for version compatibility and update or replace the incompatible extensions. **Can a single bad extension take down the whole store?** Yes. Because one OpenCart codebase serves every `store_id`, a fatal introduced by one extension affects all your storefronts at once. That is exactly why this alert runs in real time rather than on a daily summary. **What should I do the moment this alert fires?** Identify the most recent change (an install, an upgrade, a modification refresh), disable or roll it back, and refresh modifications under Extensions → Modifications. Then re-test on a staging copy rather than the live store. The fastest recovery is almost always a rollback, not a live code fix. **Does this catch database or hosting outages too?** Partially. A database error OpenCart can still report will appear in the error log and can trip the spike. A total server crash that stops PHP from running at all may never reach the in-app log; for that, pair this with an external uptime monitor. *** ### Tracked live in Vortex IQ Nerve Centre *Platform Error Spike or Extension Conflict* is one of hundreds of KPI pulses Vortex IQ tracks across OpenCart and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.