# PrestaShop 500, 404 and Checkout Error Alerts (DataFirefly Site Alerts)

> DataFirefly Site Alerts sends an email to the addresses you choose when your PrestaShop 8 or 9 shop returns a 500 error, builds up 404 errors, or a customer reaches…

- Page: <https://www.datafirefly.com/en/documentation/dfsitealerts/>
- Language: en
- Last updated: 2026-10-26
- Other languages: [fr](https://www.datafirefly.com/documentation/dfsitealerts/index.md), [es](https://www.datafirefly.com/es/documentation/dfsitealerts/index.md), [de](https://www.datafirefly.com/de/documentation/dfsitealerts/index.md), [it](https://www.datafirefly.com/it/documentation/dfsitealerts/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfsitealerts/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfsitealerts/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfsitealerts/index.md)
- Index: <https://www.datafirefly.com/en/documentation/llms.txt>

DataFirefly Site Alerts sends an email to the addresses you choose when your PrestaShop 8 or 9 shop returns a 500 error, builds up 404 errors, or a customer reaches checkout with no carrier or no payment method offered. This documentation covers installation, settings, the content of each alert and troubleshooting.

## Installation

1. In the back office, open **Modules > Module Manager**, click **Upload a module** and send the file `dfsitealerts-1.0.0.zip`.
2. The module creates its table and a tab **Advanced Parameters > Error and checkout alerts**. The module's Configure button leads straight to it.
3. On installation, the shop email address is used as the recipient and all four detections are enabled.
4. Click **Send a test email** to check that alerts arrive.

The module is compatible with PrestaShop 8.0 to 9.x and multistore. It uses no Composer dependency. Emails go through the configuration in **Advanced Parameters > E-mail**: if emails are disabled there, a warning is shown at the top of the module page.

## Dashboard

The top of the page shows the number of distinct problems detected in the last 24 hours, by type: Error 500, Error 404, No carrier, No payment method, Site unreachable. The same URL or the same error counts once. Below are the current recipients, the cron URL and the buttons **Send a test email**, **Run the scheduled task now** and **Empty the log**.

## Recipients

- **Email addresses**: one address per line (commas and semicolons are also accepted). Each address receives its own email. An invalid address is rejected when saving.
- **Language of the alerts**: language of the emails, independent of the visitors' language. By default, the shop's default language.

## What triggers an alert

Each detection can be enabled or disabled separately.

### Server errors (500)

At the end of each front office request, the module captures PHP fatal errors, uncaught exceptions and any page that answers with a 5xx status. Maintenance mode (503) is ignored. The email contains:

- the error message and the stack trace, with the server path removed;
- the PHP error type, the file and the line as a relative path;
- the URL, the referer, the HTTP method, the controller and the user agent;
- peak memory and the PrestaShop and PHP versions.

When PrestaShop catches a `PrestaShopException` and displays its error page, no PHP message is available: the module takes the last entry of the day's `var/logs/YYYYMMDD_exception.log` file. Identical errors are grouped together, with variable numbers (IDs, memory sizes) ignored for grouping.

### Pages not found (404)

404s are grouped by URL path. Parameters that identify a page (`controller`, `id_product`…) are kept, tracking parameters (`utm_*`, `gclid`, `fbclid`, `msclkid`…) are ignored. An alert is sent according to the settings in the next section.

### Checkout without any carrier

The detection triggers when a customer reaches the shipping step with a delivery address and a cart that is neither empty nor virtual, and no carrier is offered. Problems are grouped by country and state. The email contains:

- the cart ID and customer ID, the country, the state, the postcode and the zone;
- the cart weight and total, the list of products and the customer group;
- **Active carriers for this zone and group**, each with the reason it is missing: outside its weight ranges, outside its price ranges, package size too large, excluded by product restrictions or package split, or not returned for this cart (carrier module or shipping cost unavailable);
- **Products limited to some carriers**: the products in the cart that have carriers selected in their Shipping tab.

If no active carrier is assigned to the customer's zone and group, the alert says so directly.

### Checkout without any payment method

The detection triggers when a customer reaches the payment step with a cart to pay and no payment module offers an option. A free cart (total of 0) is not concerned. Problems are grouped by country, currency, carrier and group. The email contains the country, the currency, the selected carrier, the total, the customer group, then:

- **Active payment modules**: all installed and enabled payment modules;
- **Payment modules allowed for this country, currency, group and carrier**: those that the restrictions in **Payment > Preferences** let through for this customer.

If the second list is empty, the cause lies in the restrictions. If it contains modules, those modules are allowed but returned no option: the cause lies in their own configuration (minimum amount, account not connected, test mode).

## 404 settings

- **Alert threshold**: an alert is sent when the same URL reaches this number of visits since its last alert. 5 by default, 1 to alert on the first visit.
- **Immediate alert for broken internal links**: when the referer belongs to your shop, the alert is sent on the first visit, whatever the threshold.
- **Ignore bots**: search engines, SEO crawlers, scripts and empty user agents.
- **Ignore static files**: images, CSS, JS, fonts and videos.
- **URLs to ignore**: one path per line, `*` matches anything. The default list ignores common scans: `/wp-*`, `/wordpress/*`, `/xmlrpc.php`, `*/.env`, `*/.git/*`, `/cgi-bin/*`, `*phpmyadmin*`, `/.well-known/*`, `/apple-touch-icon*`.

## Sending limits and daily summary

- **Delay between two alerts for the same problem**: 60 minutes by default. Occurrences during this delay are counted and shown in the next alert, on the line “Occurrences since last alert”.
- **Maximum alerts per hour**: 20 by default, 0 for no limit. Problems beyond the limit remain recorded and appear in the summary.
- **Daily summary**: one email per day at the time you choose (8:00 by default), listing every problem recorded since the previous summary, including those that stayed below the alert threshold. It is not sent if nothing happened.
- **Keep the log for**: 30 days by default, from 1 to 365.

## Scheduled task

500, 404 and checkout alerts are sent in real time. The scheduled task sends the daily summary at the scheduled time, replays alerts that could not be saved in the database, purges the log and runs the availability check. Running it every 15 minutes is suitable.

### Cron via URL

```
*/15 * * * * curl -fsS "https://your-shop.com/module/dfsitealerts/cron?token=…" > /dev/null
```

The exact URL, with its token, is displayed on the module page with a Copy button. It answers in JSON and also works in maintenance mode. An invalid token returns a 403 error.

### Cron from the command line

```
*/15 * * * * php /path/to/prestashop/modules/dfsitealerts/cron.php > /dev/null
```

The command processes all active shops in multistore.

### Without cron

After a normal visit to the shop, the module runs maintenance at most once every 15 minutes. The summary is therefore sent after the first visit following the scheduled time. The availability check does not run in this mode.

## Availability check

Some 500 errors happen before PrestaShop starts (PHP-FPM crash, broken configuration file): no module can capture them. On each cron run, the availability check loads from the server the URLs listed in **URLs to test** (10 at most, the home page if the list is empty). A 5xx response or a failed connection triggers the **Availability check failed** alert, with the HTTP code, the response time and the connection error. A 503 is ignored when the shop is in maintenance mode.

Add a category page and a product page for better coverage. For a complete server outage, which also stops the cron from running, use an external uptime monitoring service as well.

## Alert log

The list at the bottom of the page shows each recorded problem: type, location (URL, or country / currency / carrier for checkout), message or referer, number of occurrences, first and last detection, date of the last alert. It can be filtered by type and exported to CSV. The View button opens a detail page with the same content as the email and the raw data in JSON. Deleting an entry resets its counter.

## Data and privacy

- Checkout alerts contain the cart ID and customer ID, the country, the state, the postcode, the weight and the cart contents. They contain no name, postal address, email or phone number.
- The server path is removed from error messages and stack traces.
- The log is purged after the retention period you choose.
- When the database refuses the write, the alert is kept in a file in `var/logs` (2 MB at most) and replayed at the next maintenance run.

## Known limitations

- Only the front office is monitored. Back office errors do not trigger alerts.
- A complete server or PHP outage prevents any email from being sent: use an external uptime monitoring service.
- Checkout detections rely on the native PrestaShop checkout process. With a third-party one-page checkout module, the carrier alert depends on the `displayBeforeCarrier` hook being called, and the payment alert is only evaluated once a carrier has been chosen.
- Sending after the page is displayed requires PHP-FPM or LiteSpeed. With another PHP execution mode, the email is sent before the request ends.

## Troubleshooting

### The test email does not arrive

Check **Advanced Parameters > E-mail** and send a test email from that page. Also look in the spam folder: add the shop's sender address to your contacts.

### I receive too many 404 alerts

Raise the **Alert threshold**, add the paths concerned to **URLs to ignore**, or create the missing 301 redirects: a redirected URL no longer returns a 404.

### No checkout alert although a customer complained

Check that both checkout detections are enabled and that the customer actually reached the step concerned with an address. With a third-party one-page checkout module, see the Known limitations section.

### “The cron task has never run.” remains displayed

Open the cron URL in a browser: it should answer `{"ok":true,…}`. An `invalid token` response means the URL was copied incompletely.