The number of entries written to your OpenCart system error log in the last 24 hours, the rolling pulse of self-hosted platform health.
At a glance
OpenCart writes a system error log every time the framework or an extension hits a PHP error, a database problem, or a handled exception. This card counts how many entries landed in that log over the last 24 hours. On a healthy store the number is small and stable: a handful of deprecation notices, the odd transient. A jump means something changed, a freshly broken extension, a template edit gone wrong, a PHP version mismatch, a database hiccup. Because OpenCart is self-hosted, this log is your primary window into platform health, and the 24-hour count is the simplest way to keep an eye on it.
| What it counts | The number of entries written to the OpenCart system error log (System → Maintenance → Error Logs) in the trailing 24 hours. |
| Log source | The in-application error log OpenCart writes through its own logging. This is distinct from the web server’s PHP error log, which captures errors from before OpenCart bootstraps. |
| What lands in the log | PHP warnings and notices, fatal errors that OpenCart can still record, database errors, and exceptions thrown by core or by extensions. |
| Baseline | ”Normal” is store-specific. A store with a few deprecation notices per hour has a different baseline from one running PHP-strict with zero. The spike alert is measured against the store’s own baseline. |
| Currency / refunds / orders | Not applicable. This is an infrastructure-health count, not a money or order metric. |
| Multi-store | One OpenCart install shares a single codebase and a single error log across all store_id storefronts; the count is install-wide, not per store. |
| Time window | 24H (rolling 24-hour count) |
| Alert trigger | spike > 2 sigma above baseline |
| Roles | owner, operations |
Calculation
Worked example
A UK auto-parts store on OpenCart 4.x. The error log normally records around 80 to 120 entries in any 24-hour span, mostly deprecation notices from two older extensions. On 14 Mar 26 a developer edits the product-page template to add a fitment-guide widget.| 24h window ending | Log entries | Baseline | Note |
|---|---|---|---|
| 13 Mar 26, 23:59 | 104 | ~100 | Normal |
| 14 Mar 26, 12:00 | 118 | ~100 | Normal |
| 14 Mar 26, 18:00 | 1,640 | ~100 | Spike, alert fires (well past 2 sigma) |
| 15 Mar 26, 06:00 | 220 | ~100 | Settling after fix |
| 15 Mar 26, 18:00 | 109 | ~100 | Back to baseline |
- A template edit, not an extension, caused it. The fitment-guide widget referenced a product attribute that did not exist on every product. On any product missing that attribute, the template threw a PHP warning on page load. With thousands of product views a day, the warnings stacked into the thousands.
- The count is a symptom; the log content is the diagnosis. The 24-hour count told the merchant that something was wrong and roughly when it started (between the 12:00 and 18:00 windows). Opening the actual log under System → Maintenance → Error Logs showed the repeated warning and the exact file and line, which pointed straight at the new template code.
- No orders failed, which is why a count matters. The store kept taking orders the whole time; nothing visibly broke. Without a log-volume pulse, this kind of slow-burn error storm can run for days, bloating the log file and masking new, more serious errors underneath the noise.
- The fix collapsed the count overnight. Wrapping the widget in a check for the attribute’s existence stopped the warnings. The 24-hour count drained back toward baseline as the spiked window rolled off, no manual log clearing required.
Sibling cards merchants should reference together
| Card | Why pair it with Error Log Volume (24h) |
|---|---|
| Platform Error Spike or Extension Conflict | The real-time alert built on this same log. This card is the 24-hour trend; that one fires the instant a spike or conflict appears. |
| Extension / Modification Conflicts | A common cause of log spikes. When the count jumps, check here for a colliding modification. |
| Installed Extensions / Modules | A recent install is the usual suspect behind a new error storm. |
| OpenCart Version Status | PHP and core version mismatches flood the log with deprecation and fatal errors. |
| Order Processing Backlog | If the errors are in a payment or shipping extension, the backlog stalls at the same time as the log spikes. |
| Failed Orders (24h) | Errors in the checkout or payment path show up as both log entries and failed orders. |
Reconciling against OpenCart
Where to look in the OpenCart admin: System → Maintenance → Error Logs shows the raw OpenCart error log, the exact source this card counts. You can read individual entries (file, line, message), download the log, or clear it. The “Clear” action empties the file but does not reset this card’s history. Extensions → Modifications is the next place to look when a spike coincides with a recent install or refresh. OpenCart admin views that look like the same number but aren’t:- The web server’s PHP error log (in your hosting panel or a system path) is a superset; it captures pre-bootstrap fatals OpenCart never sees. Counts will not match.
- A freshly cleared error log shows zero in the admin while this card still holds the trailing 24-hour history.
- The Dashboard shows no error information; a clean-looking dashboard can sit on top of a flooding log.
| Reason | Direction of divergence |
|---|---|
| Timezone. The 24-hour window is evaluated in UTC by default; the admin log timestamps follow the server timezone. The window edges line up differently. | Cosmetic timing shift |
| Log clearing. Clearing the log under System → Maintenance empties the admin view; the card keeps its rolling 24-hour count from history. | Admin lower than the card |
| Server-level errors. Fatals that stop OpenCart from booting may never reach the in-app log and so are not counted here. | Card under-counts catastrophic failures |
Multi-store. One log for all store_id storefronts; the count is install-wide and cannot be split per store. | Not separable |
| Log rotation. If your host rotates or truncates the log file, recent entries can be lost before the card reads them. | Card lower after rotation |
| API / DB sync lag. The most recent minutes of entries may not yet be reflected. | Self-resolves at next sync |
Known limitations / merchant FAQs
Is a non-zero error count bad? Not by itself. Almost every OpenCart store logs some background noise, mostly PHP deprecation notices from older extensions. What matters is the trend. A stable baseline is fine; a sudden multiple of it is the signal, which is why the alert is a 2-sigma spike rather than any-entries-at-all. Why count from the in-app log and not the server log? The in-app log is what OpenCart itself records, so it maps cleanly to OpenCart admin actions and extensions. The server PHP log is a superset that includes pre-bootstrap fatals; it is valuable but harder to attribute. For catastrophic failures that stop OpenCart booting, you still need the server log. I cleared the log but the card still shows a high number, why? Clearing the log under System → Maintenance empties the file in the admin, but this card counts the trailing 24 hours from history, so it does not reset on a clear. The count will fall on its own as the spiked window rolls off. A single broken page is throwing thousands of warnings, is that one error or thousands? Thousands, as far as this count goes, because each page load writes an entry. That is intentional: a high-traffic page throwing a warning on every view is a real, growing problem (it bloats the log and hides other errors), even though the root cause is one bug. Fix the bug and the count collapses. Does this count errors from all my storefronts? Yes. A single OpenCart install shares one codebase and one error log across everystore_id. The count is install-wide and cannot be split per store.
My count spiked right after a PHP upgrade, what happened?
A PHP version bump frequently breaks older extensions that called removed or deprecated functions, flooding the log with new warnings or fatals. Check OpenCart Version Status and update or replace the incompatible extensions.
Should I just turn error logging off to keep the count down?
No. The log is your main window into platform health on a self-hosted cart. Turning it off hides problems rather than fixing them, and it removes the diagnostic content you need when a spike does happen. Fix the source of the errors instead.