Every tenth of a second counts: When mobile load time dropped by 0.1 seconds, retail conversions rose by 8.4% (Deloitte). A complete outage? Lost revenue, frustrated customers, SEO damage. Professional shop monitoring detects problems in under 60 seconds - long before customers notice them. This is particularly critical for shops with optimized checkout. This guide shows how to reliably monitor your online shop.
Why Shop Monitoring Is Essential
An online shop is not a static website - it's a complex system of web server, database, payment provider, integrations, and external services. Any component can fail.
- Direct revenue losses: No shop = no orders. At €100,000 daily revenue, one hour of downtime costs €4,166
- Trust loss: Customers who see an error often don't return
- SEO damage: Google negatively evaluates outages and slow pages - rankings suffer
- Cascade effects: A small problem (full disk) becomes a major outage
- Response time: Without monitoring, you learn about problems through customer complaints
Every minute of IT outage costs companies money. For online shops, reputational damage comes on top - an outage during a campaign can be devastating.
The Four Pillars of Shop Monitoring
Uptime Monitoring
Is the shop reachable? HTTP status code, SSL certificate, DNS resolution.
Performance Monitoring
How fast is the shop? Load times, TTFB, Core Web Vitals.
Error Tracking
What errors occur? JavaScript errors, PHP exceptions, 404/500 codes.
Alerting
Who gets notified how? Email, SMS, Slack, PagerDuty.
1. Uptime Monitoring
The foundation of any monitoring: Is the shop reachable? Uptime monitoring regularly checks (every 1-5 minutes) whether the website responds.
What Should Be Checked
- HTTP status: Does the server return 200 OK?
- SSL certificate: Is it valid and not about to expire?
- DNS resolution: Does the domain resolve correctly?
- Keyword check: Does the page contain the expected content (not just an error page)?
- Important endpoints: Home page, product pages, checkout, API endpoints
Check from several locations. A local network fault at one provider should not be counted as a global outage - but a real outage should be detected from every location.
Uptime Targets (SLA)
| Uptime | Downtime/Year | Downtime/Month | Recommendation |
|---|---|---|---|
| 99% | 87.6 hours | 7.3 hours | Insufficient for e-commerce |
| 99.5% | 43.8 hours | 3.65 hours | Minimum for small shops |
| 99.9% | 8.76 hours | 43 minutes | Standard for e-commerce |
| 99.95% | 4.38 hours | 22 minutes | Recommended for high-revenue |
| 99.99% | 52 minutes | 4.3 minutes | Enterprise level |
For most online shops, 99.9% uptime is a realistic and sensible target. That means at most 8.76 hours of downtime per year - spread across planned maintenance and unplanned incidents.
2. Performance Monitoring
A shop can be reachable - but if it takes 10 seconds to load, the customers are gone. Performance monitoring measures load times continuously.
Key Metrics
- TTFB (Time to First Byte): Time until server responds. Target: under 200ms
- LCP (Largest Contentful Paint): Time until largest visible content loads. Target: under 2.5s
- FID/INP (Interaction Delay): Time until page responds to clicks. Target: under 100ms
- CLS (Cumulative Layout Shift): How much does layout shift? Target: under 0.1
- Full load time: Time until everything is loaded. Target: under 3-4s
These metrics are also the Core Web Vitals - Google's ranking factors for user experience. Poor values hurt not only conversion but also SEO.
Synthetic tests (from the monitoring tool) show what could happen. Real user monitoring (RUM) shows what actually happens - with real users, real devices, real networks.
Spotting Performance Trends
A single measurement says less than the trend over time. Good performance monitoring shows:
- Baseline: How fast is the shop normally?
- Anomalies: When does performance deviate significantly?
- Degradation: Is the shop getting slower over time (creeping problems)?
- Peaks: When is the load highest? (campaigns, time of day)
3. Error Tracking
Errors happen - the question is: do you know about them? Error tracking collects and analyzes errors in real time.
Types of Errors
- HTTP errors: 404 (page not found), 500 (server error), 503 (overloaded)
- JavaScript errors: Uncaught exceptions that break features in the browser
- Backend errors: PHP exceptions, database timeouts, API errors
- Business logic errors: Checkout abandonments, failed payments
Professional error tracking (Sentry, Bugsnag, Rollbar) delivers not only the error but also context: which user? which browser? which steps led to the error?
Prioritizing Errors
Not every error is equally critical. A sensible prioritization:
| Priority | Description | Response Time |
|---|---|---|
| P1 - Critical | Shop completely down, checkout broken, data loss | Immediate (< 15 min) |
| P2 - High | Important function broken (search, cart), many users affected | < 1 hour |
| P3 - Medium | Feature limited, workaround possible, few users | < 24 hours |
| P4 - Low | Cosmetic errors, edge cases, no business impact | Next sprint |
4. Alerting Configuration
Monitoring without alerting is useless - if nobody is notified, even the best surveillance achieves nothing. But too many alerts lead to alert fatigue - and then they get ignored.
Alert Channels
- Email: For low priority, asynchronous notification
- Slack/Teams: For team visibility, quick coordination
- SMS: For critical alerts outside working hours
- PagerDuty/Opsgenie: For 24/7 on-call with escalation
- Phone: For P1 incidents when SMS isn't enough
Who is notified first? And if there is no response after 15 minutes - who next? Define escalation chains for critical alerts so that problems do not sit unattended.
Alert Thresholds
Good thresholds avoid false alarms while still detecting real problems reliably:
- Uptime: Alert on 2 failed checks out of 3 locations (avoids flapping)
- Response time: Alert when TTFB exceeds 1s for more than 5 minutes (not on single spikes)
- Error rate: Alert when the error rate exceeds 5% for more than 2 minutes
- SSL: Warning 30 days before expiry, critical 7 days before expiry
Monitoring for Shop Systems
Monitoring requirements differ depending on the shop system:
Shopware 6 Monitoring
Shopware 6 comes with its own health checks. What to watch:
- Queue workers: Are the message queue consumers running? Are jobs piling up?
- Scheduled tasks: Are cron jobs (indexing, cache) being executed?
- OpenSearch: Is the index up to date? Does search work?
- Cache: Is Redis/Varnish reachable and performant?
- Storage: Do all file systems (public, private, temp) have enough space?
WooCommerce Monitoring
WooCommerce is based on WordPress. Specific checks:
- WP-Cron: Does the WordPress cron run reliably?
- Action Scheduler: Are asynchronous jobs being processed?
- Plugin updates: Are critical security updates available?
- REST API: Is the WooCommerce REST API reachable?
- Checkout flow: Synthetic test of the complete checkout process
Costs and Providers
Monitoring does not have to be expensive - but free is rarely sufficient. An overview; tariffs and scope change over time, so each provider's own price list is authoritative:
| Provider | Strengths | Entry level |
|---|---|---|
| UptimeRobot | Simple uptime monitoring | Free tier with limited scope |
| Pingdom | Uptime and performance, straightforward | Paid from the entry tier |
| Datadog | Comprehensive, APM, logs, metrics | Paid, billed per host |
| New Relic | Strong APM, real user monitoring | Free tier with limited scope |
| Sentry | Error tracking, release tracking | Free tier with limited scope |
| Grafana Cloud | Open-source based, flexible | Free tier with limited scope |
For most online shops a combination makes sense: an uptime tool (Pingdom, UptimeRobot) plus error tracking (Sentry) plus performance (Google Lighthouse CI, RUM).
Checklist: Shop Monitoring Setup
- Uptime monitoring set up for home page, product pages, checkout and API
- Several geographic locations configured
- SSL certificate monitoring active
- Performance baseline determined and thresholds defined
- Error tracking implemented in the frontend (JavaScript) and backend
- Alert channels configured (email, Slack, SMS)
- Escalation chains defined for critical incidents
- Runbook or documentation written for common incidents
- Regular review of the alerts (weekly or monthly)
For e-commerce, we recommend 1-minute intervals for critical endpoints (homepage, checkout) and 5-minute intervals for secondary pages. More frequent checks mean faster detection but also more cost.
99.9% is the standard for e-commerce - that's a maximum of 8.76 hours of downtime per year. For high-revenue shops, 99.95% or better should be targeted.
Ideally both. External monitoring (from outside) shows what customers see. Internal monitoring (server metrics) shows why something happens. The combination enables quick diagnosis.
Define sensible thresholds that detect real problems but avoid noise. Use confirmations (2 of 3 checks failed) and group related alerts.
Basic monitoring (uptime, SSL) is easy to set up yourself. For comprehensive performance monitoring, error tracking, and APM, we recommend professional support - misconfigured monitoring can do more harm than good.
Synthetic monitoring simulates requests from a monitoring tool - ideal for checking availability and response times around the clock under constant conditions. Real User Monitoring (RUM) measures the actual experience of real visitors with their devices and networks. In practice, the two complement each other: synthetic tests reliably detect outages, while RUM shows real-world performance in the field.
Prevention Over Firefighting
Professional shop monitoring is indispensable for every online shop. It costs a fraction of what a single multi-hour outage would cost. With uptime monitoring, performance tracking, error logging, and smart alerting, you detect problems before your customers notice them.
We set up professional monitoring for your Shopware or WooCommerce shop - including hosting with integrated monitoring. Contact us for consultation.
This article is based on data from Deloitte (Milliseconds make Millions), Google Web Vitals, and best practices from Site Reliability Engineering (SRE). As of: September 2026.