Skip to content
Proactive security updates

Monitoring & incident response

An outage becomes expensive when it is first noticed through a customer call. This category covers monitoring and response: availability checks from several networks, monitoring critical flows such as cart and checkout, certificate and domain expiry, error rates and response times, disk space and queues. We show how to set thresholds so alerts are taken seriously instead of drowning in noise, and what an on-call procedure with clear responsibilities looks like. Added to this are recovery plans: which backups exist, how long a restore actually takes, who informs customers and service providers. Post-incident review and root cause analysis are part of it as well. We also cover communication: which information customers and service providers need during an incident and who approves it.

.de DNS outage, 5 May 2026: shop was up, customers saw SERVFAILServer, shop software, certificate: all healthyDomain resolution: SERVFAILSignature chain of the .de zoneWhat different resolvers make of itRoot zone: DS record for .de.de zone: DNSKEY publishedRRSIG with key tag 33834 - not validatableshop.de: A record still correctUnsigned .de domains affected too (NSEC3 proof)Validating resolver (DNSSEC checking on)Verify signatureResult: bogusSERVFAIL to the customerCustomer behind a public or corporate resolver: the shop does not existNon-validating resolver (checking off)No verificationAnswer acceptedShop reachable - HTTP 200Uptime check from this location: green - the outage stays invisibleCourse of the incident - 5/6 May 2026 (DENIC eG, heise online)21:43 CESTfirst faulty RRSIG21:50 CESTmonitoring raises alarms00:08 CESTcorrected zone rolled out01:15 CESTnormal operation restored3 hrsduration of the .de disruption(DENIC eG)33 %validatable .de signatures(DENIC eG)18Mregistered .de domains(DENIC eG, June 2026)DNS maintenance: signature chain, registry lock and resolver-aware monitoring as their own layer

DNS Maintenance for Shops: DNSSEC, Locks, Monitoring

The DENIC outage of 5 May 2026 showed: a shop can be unreachable while everything runs. Maintain the DNSSEC chain, domain locks and resolver-aware monitoring.

13 min read
Response-Time SLA: Severity, MTTR and EscalationSeverity Levels — Response and Resolution (MTTR)LevelResponseResolution (MTTR)CoverageP1 critical15 min4 h24/7P2 high1 h8 h24/7P3 medium4 bus. h24 h8x5Escalation Chain (P1)1Alarm triggeredMonitoring detects outage · 0 sec2L1 On-callresponds and acknowledges · target 15 min3L2 Engineerauto handover after 15 min, no response4L3 Team leadif still unresolved after 30 minIncident Timeline (today)02:14Alarm: checkout unreachableclassified as P102:16L1 on-call acknowledgedResponse (MTTA) 2 min02:41Root cause isolated, fix deployedverified on staging02:56Resolved: checkout back onlineResolution (MTTR) 42 min · SLA met

Response-Time SLA: What Good Emergency Support Does

Response-time SLA for online shops: severity levels P1 to P4, realistic MTTR values and how to recognize reliable emergency support with a committed response.

13 min read
What a Shop Outage Costs per MinuteDirect revenue loss2,000 EUR+per minute (SMB shop, peak hours)Indirect follow-on costs5 to 10xreputation, churn, lost CLVCost curve during the outage0-2 min5 min10 min20 min30 min45 min60 minDetection < 2 min$15,000peak cost per minuteindustry-wide average forlarge organisations in 2026$600Bannual downtime costacross Global 2000 firms,up 50 percent in two years3.4%average stock-price dropfollowing a singledowntime incident24/7 monitoring reports the outage before the first customer notices

Downtime Cost 2026: What a Shop Outage Costs per Minute

What a shop outage costs per minute in 2026: direct and indirect costs, why detection under 2 minutes matters and how 24/7 monitoring protects revenue.

12 min read
Performance Monitoring in the Maintenance ContractLive Dashboard: Uptime + Response Time + Core Web Vitals + SLA ReportingUptime (30 days)99.96%Target SLA 99.9%Response time p75248msBudget 400msLCP p751.9sThreshold 2.5sResponse time trend against SLA target lineSLAAlert: response-time regression detectedTrigger: p75 248ms briefly exceeds budgetCause: new plugin after update (regression watch)Escalation: email instantly, then SMS after 5 minStatus: acknowledged, rollback in maintenance windowMonthly ReportSLA metAvailability99.96%Avg. response212msCWV status3/3 goodIncidents10.1s faster load = +8.4% retail conversions (Google/Deloitte, Milliseconds Make Millions)

Anchor Performance Monitoring in Your Maintenance SLA

Make performance monitoring a fixed SLA component: performance budgets, alerts, monthly reports and regression watch for consistently fast online shops.

13 min read
Log Monitoring and Alerting for Online Shops1. Log sourcesWeb server (nginx/Apache)Shopware PHP-FPMMySQL slow query logPayment / API gatewayCron jobs and workers2. Aggregation and parsingCentral log pipeline (JSON)level=ERROR trace_id=a91f order_id=10493level=WARN status=502 route=/checkoutlevel=INFO event=payment.ok 245msIndex + full-text search + retentionLogs - metrics - traces correlated via trace_id3. Alert rulesError rate 5xx > 2%over 5 min - criticalp95 latency > 2scheckout - warningAnomaly: 0 ordersin 15 min - critical4. Escalation and on-callLevel 1chat + push instantLevel 2SMS after 5 minLevel 3on-call call after 15 minLevel 4lead after 30 minAvoid alert fatiguesymptom-based, deduplicated, with severityonly actionable alerts reach on-callIncident responserunbook - diagnose via trace_id - postmortemlower MTTR, not just count MTBFResult: problems surfaced early - precise alerts - fast diagnosisStructured logging | log levels | aggregation | thresholds | anomalies | on-call | postmortem

Log Monitoring and Alerting for Online Shops Guide

Structured logging, central log aggregation, meaningful alerts and escalation: detect problems in your online shop before your customers ever report them.

13 min read
Checkout Monitoring: the Silent Order FailureUptime signal: HTTP 200 OKRevenue: 0 ordersSynthetic transaction check - buy funnel every minute from 3 regions1. Product pagePrice 49.90 €Stock: availableOK 210 ms2. CartItem in cartCoupon -10%OK 340 ms3. CheckoutAddress checkedShipping calculatedOK 520 ms4. PaymentGateway timeoutOTP step lostFAILED 4/4!Transaction check failedStep 4/4 - Payment: gateway timeout3 of 3 regions confirm the failureThreshold: 2 failed runs / 2 regions metThree layers - one viewUptime: reachable? (green but blind)Log: backend error? (no entry)Transaction: can they buy? (failing)70%average cart abandonment(Baymard Institute)15%abandon due to site errors(Baymard Institute)+8.4%conversion per 0.1s faster(Deloitte)Synthetic transaction monitoring catches the silent failure before revenue drops

Checkout Monitoring: Catch Silent Order Failures

Synthetic transaction monitoring catches silent checkout failures: check cart, coupon, payment and OTP every minute from several regions before revenue drops.

12 min read