PrestaShop 1.7 and 8 module

The back office tells you the store is down before a customer does

Upload the module, give an email address, and you are set. PingView checks the store from five countries, watches the cart and the checkout, the certificate and the speed, and reports it in the back office you open every day anyway.

  • Free, no card
  • No code on customer requests
  • Panel in the back office in 2 minutes

version 1.9.0 · requires PrestaShop 1.7.6.0+ · PHP 7.2+

your-store.com/admin

PingView

your-store.com

Operational

Status

Operational

Uptime, 24h

99.98%

Response time

284 ms

Needs attention

All clear

Availability

24h agonow
Last 24 hours
99.98%
Last 7 days
99.91%

Checked from 5 locations

  • PLWrocław118 ms
  • DEFrankfurt173 ms
  • GBWorcester140 ms
  • USNewark248 ms
  • ITMilan296 ms

The SSL certificate expires in 26 days. Renew it before the browser starts warning your customers.

The plugin panel inside your store's own admin. Location and card names are real; the numbers are illustrative.

Three nights the store was not selling

This is not about charts. It is about who tells you, and how long that takes.

3:40 in the morning, the host restarts the database
Without monitoringThe store answers 500 for forty minutes. You find out in the morning, from a customer who could not pay.
With the PingView pluginAn alert after the second failed check, by email and on the channel your team watches anyway.
Tuesday, the SSL certificate expires
Without monitoringThe browser shows a scary warning. Traffic is there, carts are not, and the cause looks like a bad campaign.
With the PingView pluginThe panel counts down the days to expiry and reminds you thirty days ahead. Same for the domain.
Friday, a new theme goes live
Without monitoringOn your desk everything flies. On a customer's phone the checkout takes eight seconds and half the carts stay empty.
With the PingView pluginLighthouse and Core Web Vitals measured from outside after changes, and a performance drop over twenty percent is an alert.

Six questions the panel answers without a single click

The plugin computes nothing on its own. It renders what the PingView backend computed, in the place you happen to be.

Is the store up right now?
One word in the header: operational, degraded, partial, offline or maintenance. Exactly the state your team sees in PingView and your customer sees on the status page.
Is it my store or my connection?
The result from every probe separately: Wroclaw, Frankfurt, Worcester, Newark, Milan. Four see the store and one does not, so this is not a store outage.
How long was the store down this week?
Uptime for 24 hours and for 7 days, plus an hour-by-hour chart. No spreadsheet arithmetic, and no argument with the host about whether the outage happened at all.
Is the checkout actually taking orders?
A synthetic purchase path walks the cart and the checkout and asserts that the steps really happened. A homepage can answer 200 long after the payment step has died.
What should I fix first?
A list of things to do, most urgent first: an expiring certificate, a missing security header, a page that got slower. Sentences to tick off instead of a chart to interpret.
Who finds out while I am asleep?
Email works out of the box. Then you route incidents to the channel your team already watches: Slack, Microsoft Teams, Discord, a webhook or SMS.

Checkout can be dead while the homepage is green

The homepage answers 200, so an ordinary uptime monitor stays green while the payment module has already broken after an update. The module marks the cart, the checkout, a category and a product as addresses to watch, and a synthetic purchase path walks them step by step and checks that the steps actually happened.

The plugin computes nothing on your server

A store that is down cannot report that it is down. So the checks run from outside, and the plugin is only a window onto the result.

No code on customer requests

Not a line of the plugin runs when a customer opens a page. Nothing is added to the store's response time and nothing lands on the storefront.

Checks from five countries

The probes run on our servers in Poland, Germany, the United Kingdom, the United States and Italy. An outage at your host does not touch them.

Disconnecting does not stop the monitoring

Disconnecting removes the credentials stored in the store. The monitor keeps running, the history stays, the alerts still arrive.

Twenty cards every plugin has to render

This is a contract, not a feature list: a plugin build fails if one of these cards disappears from the panel. We also show the three places where one platform does less than the others.

Plugin panel cards and their availability on the three platforms
Panel cardWordPressPrestaShopMagento 2
Store state in one wordOperational, degraded, partial, offline or maintenance in the panel header.
Four numbers up frontStatus, 24h uptime, response time and what needs attention.
What to fixSentences to tick off, most urgent first, computed by the backend.
Uptime, 24h and 7 daysPercentages plus an hour-by-hour chart.
What exactly is checkedThe interval, the locations and the conditions that raise an alert.
Watched store addressesCart, checkout, a category and a product, discovered from your store.
Alert channelsEmail, Slack, Teams, Discord, webhook and SMS, with a link to the settings.
Each probe on its ownStatus and latency per location, so an outage is told apart from a bad link.
Certificate and domainDays to SSL and domain expiry, plus a plain-HTTP warning.
Security headersThe Mozilla Observatory grade and the headers you are missing.
Lighthouse and Core Web VitalsPerformance, accessibility, best practices and SEO, measured from outside.
Purchase pathA synthetic run through the cart and the checkout, with its assertions.no verification state
Recent incidentsWhen they started, how long they lasted and how they ended.
Is the store's schedule aliveA diagnosis of the store's cron plus a heartbeat monitor on our side.cron line on your hostingcron line on your hosting
Status badgeA preview and a snippet to paste, next to the public status page.
Repoint after an address changeWhen the store changes domain, the monitor follows it.automaticone clickone click
Account and teamWhich PingView account this store reports into.
Monitoring outside the storeA plain statement that the checks do not run on your server.
Into the full productA link to the account with history, reports and status pages.
Disconnect the storeRemoves the local credentials; the monitor keeps running.

Install

The account is created along the way, inside the store admin. Nothing to sign up for first.

  1. 1

    Download the module package from the panel beside this list.

  2. 2

    In the back office go to Modules, Module Manager, Upload a module, and pick the ZIP file.

  3. 3

    Open the PingView module configuration, enter an email address, tick the consent box and press start.

  4. 4

    The panel shows the state of the store after the first check. If you already have a PingView account, paste an API key instead of the email.

Before you install

Will the plugin slow the store down?
No. None of its code runs on a customer request and nothing reaches the storefront. The checks are made by our servers, from outside.
Do I need a PingView account first?
No. In the plugin panel you give an email address and consent, and the account, team, monitor and API key are created for you. If you already have an account, you paste a write-scoped key.
What does it cost?
The plugin is free, and the free plan is enough to watch a store. Paid plans add locations, deep scans and synthetic purchase paths.
What happens if I deactivate the plugin?
The monitor keeps running on our side and the alerts still arrive. You only lose the panel inside the store admin.
Does this replace a security or caching plugin?
No. It is an external check of what the store sends over HTTP. It caches nothing, minifies nothing, and it is neither a firewall nor a malware scanner.

Install it and see the state of your store

Two minutes inside the store admin, no card and no signing up first.