Uptime Monitoring for WordPress, Shopify & Webflow: Setup Guide

Last updated: September 1, 2026
Author: WhatPing Engineering Team

Executive Summary

Key Takeaways

• A green homepage check means almost nothing on any of these three platforms. WordPress can serve a cached homepage while the database is unreachable; Shopify can serve a storefront while checkout is broken; Webflow can serve a published page while a CMS collection integration is failing silently.
• DNS and certificate monitoring matter more for Shopify and Webflow than for most self-hosted sites, because the domain is the one piece of infrastructure you fully control on an otherwise fully managed platform, and a misconfigured CNAME during a migration is the single most common cause of a “site is down” support ticket that has nothing to do with the platform itself.
• WordPress needs internal and external monitoring; Shopify and Webflow need external monitoring done well. You can’t install an agent inside Shopify’s or Webflow’s infrastructure, so the entire monitoring burden for those two platforms falls on well-designed external checks against the right endpoints.
• wp-cron is not a real cron job, and monitoring it as if it were produces false confidence. WordPress’s default scheduled-task system fires only when a visitor loads a page, which means a low-traffic site can silently stop running scheduled tasks — backups, cache purges, plugin updates — for days without any error appearing anywhere.
• Platform status pages are a starting point, not a substitute for your own monitoring. Shopify’s and Webflow’s own status pages report platform-wide incidents, not the state of your specific store, custom domain, or theme — a per-tenant failure on either platform will not appear there.
• A single accepted-status-code check misses the most common failure mode on all three platforms: a page that returns 200 while displaying an error. A WordPress white-screen-of-death, a Shopify theme liquid error, and a Webflow CMS binding failure can all return a 200 status code with broken content, which only a keyword assertion catches.

1. Problem Statement

Each platform’s architecture creates a different, specific way for “the site looks fine but isn’t” to happen, and none of them are caught by a plain status-code check.

First, WordPress’s shared-fate stack. A single WordPress installation depends on a web server, a PHP runtime, a MySQL or MariaDB database, and however many plugins are active — any one of which can fail independently while the others report healthy. A plugin update that introduces a fatal PHP error takes down every page that loads that plugin’s code, while the server itself, the database, and unrelated pages may continue functioning normally. Basic ICMP or TCP checks against the hosting server report the machine as fully operational throughout.

Second, Shopify’s split between platform uptime and merchant-side breakage. Shopify’s own infrastructure has a strong uptime record, but a merchant’s storefront can still go effectively dark for customers through causes entirely outside Shopify’s control: a custom domain’s DNS record pointing at the wrong target after a registrar change, a theme app that injects broken JavaScript into every page, or a checkout extension that fails silently for a subset of payment methods. Shopify’s own status page will show “all systems operational” during every one of these incidents, because from the platform’s perspective, nothing is actually wrong.

Third, Webflow’s CMS and integration failure surface. Webflow separates the visual site from CMS-driven content and third-party integrations — a form that posts to a broken webhook endpoint, a CMS collection page that fails to render because a linked reference item was deleted, or a custom code embed that throws a JavaScript error blocking form submission. The published page itself typically still returns 200, because Webflow’s hosting layer is serving static, pre-rendered content regardless of whether the interactive pieces on top of it work.

Fourth, the DNS and certificate blind spot common to all three, but most acute for Shopify and Webflow. Because the domain and its DNS configuration are the one infrastructure layer a merchant or site owner fully controls on an otherwise-managed platform, misconfigurations here are both common and platform-invisible. An expiring custom SSL certificate, an accidentally deleted CNAME record during a DNS provider migration, or a forgotten domain renewal takes the site down in a way that looks, to the platform, like normal traffic simply stopping.

2. History

WordPress launched in 2003 as a fork of the b2/cafelog blogging platform, and its self-hosted architecture — meaning every installation runs on infrastructure the owner selects and manages — has remained fundamentally unchanged since, even as the plugin and theme ecosystem grew to dominate a large share of the web. Because WordPress hosting spans everything from shared $5-a-month plans to dedicated managed infrastructure, “monitoring a WordPress site” has never meant one consistent thing; it depends entirely on what the owner’s hosting stack looks like underneath the CMS.

Shopify launched in 2006, initially built by its founders to sell snowboards online before becoming a hosted e-commerce platform in its own right. Its architecture made a deliberate trade against WordPress’s model: merchants get no server access at all, in exchange for the platform absorbing all infrastructure operation, scaling, and — critically for this guide — most classes of uptime failure that would otherwise be the merchant’s problem.

Webflow launched publicly in 2013, targeting designers who wanted visual control over markup without hand-coding, and later added a CMS layer for structured content. Like Shopify, it’s fully hosted — Webflow serves published sites through its own content delivery infrastructure — but it retained more design and code-level customization surface than Shopify, which reintroduces some of the “someone’s custom code broke something” risk that fully managed platforms are supposed to eliminate.

The monitoring practices for each platform evolved along the same lines as the platforms themselves. WordPress monitoring tools — starting with plugins like Jetpack’s uptime monitoring feature and various self-hosted health-check plugins — grew up alongside the CMS’s plugin ecosystem, because the failure surface was internal to the installation. Shopify and Webflow, having no equivalent internal access to offer, pushed merchants toward external synthetic monitoring almost from the start, since there was no other vantage point available. By 2025 and into 2026, the practical convergence across all three platforms is toward the same conclusion: external synthetic checks targeting the platform’s actual public-facing failure points — not internal server metrics that either don’t exist (Shopify, Webflow) or don’t tell the whole story (WordPress) — are the common foundation, supplemented by platform-specific internal checks only where WordPress’s self-hosted model makes that possible.

3. Definition

Platform-specific uptime monitoring is the practice of configuring synthetic checks against the particular endpoints, content markers, and infrastructure dependencies that determine whether a site built on a specific CMS or e-commerce platform is actually functioning for a real visitor — as opposed to generic monitoring that checks only whether a URL returns any response at all.

This distinction matters because the three platforms covered here sit at different points on a spectrum of what you can directly observe:

• Self-hosted, full internal access (WordPress). You control the server, so you can run internal health checks — database connectivity, PHP error logs, disk space, WP-Cron execution — in addition to external synthetic checks. Internal monitoring here is genuinely useful, not redundant.
• Fully managed, no internal access, high customization surface (Shopify, and to a lesser extent Webflow’s CMS and code-embed features). You cannot install anything server-side, so monitoring depends entirely on external checks against the specific pages and interactions that customization can break — checkout flows, forms, custom scripts.
• Fully managed, minimal customization surface. A simple Webflow marketing site with no CMS collections or custom code behaves closer to a purely static site, where a well-configured external HTTP and DNS check covers nearly the entire realistic failure surface.

Where a given site falls on this spectrum determines how much of this guide’s WordPress-specific internal monitoring advice applies versus how much of the Shopify/Webflow external-only advice applies — a heavily customized Webflow site with several CMS collections and third-party embeds needs monitoring closer to the Shopify model than the “simple static site” end of its own platform’s range.

4. Architecture

WordPress monitoring architecture needs two layers working together. The external layer — synthetic HTTP checks against the public site — catches what a real visitor experiences: page load failures, slow response times, SSL problems. The internal layer, which only WordPress’s self-hosted model makes possible, checks things no external probe can see: database connection health, PHP error log entries, WP-Cron execution history, and disk space on the hosting server. Neither layer substitutes for the other — an external check can confirm the homepage loads while remaining blind to a checkout page broken by a plugin conflict that the homepage doesn’t trigger.

Shopify monitoring architecture is necessarily external-only, since Shopify provides no server access, but it needs to be external monitoring aimed at the right targets. The storefront’s public pages, the custom domain’s DNS resolution and SSL certificate, and — critically — the checkout flow itself, which involves a handoff between the merchant’s custom domain and Shopify’s checkout infrastructure that can fail independently of the storefront pages around it. A theme or app that only breaks checkout, not product browsing, is invisible to a monitor that only checks the homepage.

Webflow monitoring architecture follows the Shopify pattern for anything customized — forms, CMS collections, embedded scripts — but for simpler marketing sites without those features, external HTTP and DNS monitoring alone covers most of the realistic risk. The one Webflow-specific architectural wrinkle is the CDN layer: Webflow serves published sites through a content delivery network, which means a check needs to account for cache behavior when validating that content updates have actually propagated, rather than assuming an immediate reflection of published changes.

Across all three, the architecture that catches the most real incidents is the same: external checks against multiple specific pages — not just the homepage — combined with DNS and certificate monitoring on the custom domain, since that domain layer is the one piece of infrastructure common to all three platforms that sits outside the platform’s own guarantees.

5. Internal Working

How a WordPress health check should actually work. Rather than checking only the homepage, a proper WordPress monitor targets /wp-json/, WordPress’s REST API root, which returns a JSON response only if PHP is executing correctly and the WordPress core has bootstrapped — a fatal PHP error anywhere in the loading chain breaks this endpoint distinctly from how it might leave a cached homepage still servable. Since WordPress 5.2, the built-in Site Health feature exposes additional diagnostic data at /wp-admin/site-health.php, though that page requires authentication and isn’t suitable for external synthetic checks — its value is for manual or internally-scripted diagnosis after an external check has already flagged a problem.

How a Shopify check should target the checkout handoff specifically. A synthetic check against a Shopify store’s product page confirms the storefront renders, but checkout occurs through a distinct flow — typically a redirect from the custom domain to a Shopify-managed checkout subdomain, or an embedded checkout depending on the merchant’s configuration. Because this handoff involves a domain and certificate transition, a DNS misconfiguration or certificate problem on the custom domain can break checkout specifically while leaving product browsing entirely functional. A keyword assertion checking for expected checkout page content — not just a 200 status, since Shopify’s checkout can return 200 with a generic error state — catches this class of failure that a homepage check cannot.

How a Webflow form check should account for the CDN and the actual submission endpoint. Webflow serves static published pages through its CDN, so the page itself loading successfully says nothing about whether a form on that page actually submits. Forms typically POST to a Webflow-managed endpoint or, if configured with a custom integration, to a third-party webhook — testing form functionality requires either a scheduled synthetic submission with a distinguishable test payload, or monitoring the destination the form data flows to (a Zapier webhook, a CRM endpoint) as a heartbeat-style check, since Webflow’s own infrastructure gives no visibility into whether a downstream integration is failing.

6. Components

WordPress-specific components to monitor:

• The hosting server or platform — via TCP/ICMP for basic reachability, and via internal agent-based checks where the hosting environment allows it.
• The database connection — surfaced indirectly through the /wp-json/ health check, since a broken database connection typically breaks the REST API bootstrap.
• WP-Cron execution — via a heartbeat monitor pinged by a real cron job or a scheduled task, not by relying on WordPress’s own visitor-triggered pseudo-cron.
• Individual critical pages — checkout or contact-form pages for a WooCommerce site, not just the homepage, since plugin conflicts are often page-specific.
• SSL certificate — particularly relevant for self-managed certificates rather than ones auto-renewed by a host like a Let’s Encrypt integration.

Shopify-specific components to monitor:

• The custom domain’s DNS records — the CNAME or A record pointing to Shopify’s infrastructure, which is the most common point of merchant-side failure.
• The SSL certificate on the custom domain — Shopify manages certificate issuance for connected domains, but a domain that’s been disconnected and reconnected, or migrated between registrars, can end up in a state where the certificate briefly doesn’t cover the active domain.
• Product and collection pages — representative pages, not just the homepage, to catch theme or app-specific breakage.
• The checkout flow — specifically, since it’s architecturally distinct from storefront browsing.
• Shopify’s own status page — worth checking as a secondary signal, not a primary one, since it only reports platform-wide incidents.

Webflow-specific components to monitor:

• The custom domain’s DNS configuration — Webflow requires specific A and CNAME record configuration for custom domains, and errors here are common during initial setup or domain migration.
• Forms — either directly via scheduled test submissions or indirectly via the downstream integration endpoint.
• CMS collection pages — particularly any that pull from external data sources or use conditional visibility logic that can fail silently.
• Custom code embeds — any JavaScript that affects page functionality but not the initial page load, meaning a broken embed doesn’t produce a failed HTTP check on its own.

7. Workflow

Step 1: Inventory the actual failure surface, not just the homepage. For each platform, list the specific pages and interactions that matter — checkout, key landing pages, forms, any custom integration — rather than defaulting to a single homepage check.

Step 2: Configure DNS and certificate monitoring on the custom domain first, since this is the shared point of failure across all three platforms and the one most commonly broken during migrations, renewals, or registrar changes.

Step 3: Set up keyword-based HTTP checks on each critical page, asserting the presence of expected content rather than only the status code, since all three platforms can return 200 on a broken page.

Step 4: Add heartbeat monitoring for anything scheduled or asynchronous — WP-Cron tasks, form-to-webhook integrations, any process that doesn’t have a page a browser check can directly validate.

Step 5: Set an appropriate failure threshold and second-opinion configuration, since e-commerce and lead-generation sites are particularly sensitive to false-positive alerts during genuine traffic spikes or brief CDN cache misses, but also particularly costly when a real checkout failure goes unnoticed for an extended period.

8. Configuration

WordPress: a custom health-check endpoint via a must-use plugin, which avoids depending on a page that a broken theme or plugin might itself break:

<?php
// File: wp-content/mu-plugins/health-check-endpoint.php
add_action('rest_api_init', function () {
    register_rest_route('healthcheck/v1', '/status', array(
        'methods' => 'GET',
        'callback' => function () {
            global $wpdb;
            $db_ok = $wpdb->get_var("SELECT 1") === '1';
            return new WP_REST_Response(array(
                'status' => $db_ok ? 'ok' : 'db_error',
                'timestamp' => current_time('mysql'),
            ), $db_ok ? 200 : 500);
        },
        'permission_callback' => '__return_true',
    ));
});

This exposes https://yoursite.com/wp-json/healthcheck/v1/status, returning a 500 with an explicit db_error status if the database query fails — a more precise signal than an external monitor inferring database trouble from a generic 500 or timeout.

WordPress: a heartbeat monitor to catch a stalled WP-Cron, added to a real crontab entry that also disables the unreliable default:

# In wp-config.php, disable the default pseudo-cron:
# define('DISABLE_WP_CRON', true);

# Real crontab entry, running every 15 minutes:
*/15 * * * * curl -s "https://yoursite.com/wp-cron.php?doing_wp_cron" > /dev/null \
  && curl -fsS -m 10 --retry 3 "https://heartbeat.whatping.com/ping/YOUR_TOKEN_HERE" > /dev/null

9. Examples

Scenario: a WooCommerce plugin update breaks checkout while the homepage stays healthy. An online retailer running WooCommerce on WordPress applied a routine plugin update to a shipping-calculation extension. The update introduced a PHP fatal error that fired only when the cart contained items requiring shipping-rate calculation — meaning the homepage, product pages, and even an empty cart all continued to function normally, while any real purchase attempt hit a white screen. Standard homepage monitoring reported the site as fully up throughout the incident. A monitor configured against the actual checkout flow with a real test item in the cart — rather than just the empty cart page — would have caught this within one check cycle instead of the several hours it took for customer complaints to surface the pattern.

Scenario: a Shopify merchant’s custom domain breaks during a registrar transfer. A merchant moved domain registrars to consolidate billing, and during the transfer, the CNAME record pointing the custom domain to Shopify’s infrastructure was not correctly recreated at the new registrar. Shopify’s own infrastructure and the .myshopify.com fallback domain remained fully operational throughout — Shopify’s status page showed no incident, because from the platform’s perspective nothing was wrong. Customers attempting to reach the branded domain received DNS resolution failures for roughly six hours before the merchant noticed a drop in traffic and investigated. A DNS-specific monitor on the custom domain’s CNAME record would have caught the misconfiguration within minutes of the transfer completing, rather than depending on a traffic-drop being noticed manually.

10. Performance

WordPress monitoring overhead depends heavily on hosting tier. Shared hosting environments often apply aggressive rate limiting or bot-blocking rules that can misidentify frequent synthetic checks as abusive traffic — a monitor hitting the site every 20 seconds from a single IP can trigger the same defenses meant to stop scraping bots, producing false-down alerts that are actually the host blocking the monitor itself. Whitelisting the monitoring service’s published IP ranges at the hosting or firewall level resolves this and is worth doing proactively rather than after the first false alert.

Shopify’s own bot and traffic-shaping systems can behave similarly. Shopify applies its own protective measures against excessive automated traffic, and while legitimate monitoring services generally aren’t affected at normal check intervals, checking every unique product or collection page at very short intervals across a large catalog can accumulate into a request volume worth being deliberate about — monitoring a representative sample of pages rather than the entire catalog is usually sufficient and avoids this entirely.

Webflow’s CDN caching introduces a specific performance consideration for validating content updates rather than raw uptime: a monitor checking for newly published content immediately after a publish action may see stale cached content for a short window, which is expected CDN behavior rather than a real failure — content-update validation checks should build in an appropriate delay rather than firing immediately on publish.

11. Security

• Never expose WordPress’s wp-login.php or /wp-admin/ as a monitored keyword-check target without authentication considerations — a monitor configured to log in for deeper health checks would need to store WordPress credentials, which introduces a credential-management risk disproportionate to the value gained; external monitors should stick to unauthenticated, read-only endpoints like the custom health-check route shown in Section 8.
• Restrict the custom health-check endpoint to return only a status field, never diagnostic detail. A health-check route that returns full database error messages or stack traces on failure is handing a reconnaissance tool to anyone who requests it, monitoring service or not.
• Rotate Shopify and Webflow API credentials used for any deeper integration monitoring on the same schedule as other application secrets, and scope them to the minimum access required — read-only where the monitoring use case allows it.
• Treat a form-to-webhook integration’s endpoint URL as a credential, per the same logic WhatPing’s own security model applies to alert-channel destinations: a leaked webhook URL for a lead-capture form grants an attacker the ability to inject fraudulent submissions into your CRM pipeline.
• Whitelist monitoring service IP ranges rather than disabling bot protection broadly, so the security posture that protects against real scraping and credential-stuffing attempts stays intact while your own monitor is exempted specifically.

12. Troubleshooting

Diagnostic Step 1: Confirm whether the failure is platform-wide or specific to your domain. Check the platform’s status page (status.shopify.com for Shopify equivalents, or the relevant provider page) — if it shows no incident, the problem is almost certainly on your side: DNS, certificate, theme, or app configuration.

Diagnostic Step 2: Isolate whether the failure is page-specific or site-wide, using manual checks against multiple pages:

curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.com/
curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.com/cart
curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.com/wp-json/

A homepage that returns 200 while a checkout or health-check route fails confirms the problem is scoped to specific functionality, not the whole platform.

Diagnostic Step 3: For WordPress, check PHP error logs directly, since a fatal error visible there but invisible to a generic HTTP check confirms an application-layer problem:

tail -n 100 /path/to/wp-content/debug.log

Diagnostic Step 4: For DNS-related failures on Shopify or Webflow, verify the current record against the expected value:

dig CNAME www.yoursite.com +short

Compare the output against the platform’s documented required target — a mismatch confirms a DNS configuration problem rather than a platform-side outage.

Diagnostic Step 5: For a Webflow form or Shopify checkout failure that returns 200, check for the expected content marker manually:

curl -s https://yoursite.com/cart | grep -o "Check out"

An empty result despite a 200 response confirms the page loaded but the expected functional element didn’t render — the exact class of failure keyword-based monitoring is designed to catch.

13. Best Practices

• Monitor at least three distinct page types per site, not just the homepage: a content page, a transactional page (checkout or a lead-capture form), and — for WordPress — a dedicated health-check endpoint.
• Use keyword assertions on every transactional page, since a 200 status code alone doesn’t confirm functional correctness on any of these three platforms.
• Set up DNS monitoring on the custom domain the same day it’s configured, not after the first migration-related incident — this is the cheapest, highest-value check across all three platforms.
• Disable WordPress’s default pseudo-cron and replace it with a real crontab entry paired with a heartbeat monitor, since low-traffic sites can otherwise go days without scheduled tasks executing.
• Check platform status pages as a secondary signal, never a primary one — build your own monitoring assuming the platform’s status page will not reflect your specific incident.
• Whitelist your monitoring service’s IP ranges at the hosting or CDN level proactively, especially for WordPress sites on shared hosting with aggressive bot protection.

14. Common Mistakes

• Monitoring only the homepage and assuming it represents the whole site. The homepage is frequently the most cached, most stable page on any of these three platforms — precisely the page least likely to reveal a checkout, form, or plugin-specific failure.
• Relying on WordPress’s built-in pseudo-cron without a real scheduled trigger. A site with low or irregular traffic can go extended periods without any visitor loading a page, silently starving every scheduled task that depends on wp-cron.
• Treating a platform’s status page as sufficient monitoring. Shopify’s and Webflow’s status pages report platform-wide incidents only — a merchant-specific DNS, theme, or app failure will never appear there regardless of severity or duration.
• Storing WordPress admin credentials in a monitoring tool for deeper checks. This introduces a credential-management liability that isn’t justified when unauthenticated health-check endpoints can surface the same information more safely.
• Ignoring SSL certificate monitoring on a custom domain because “the platform handles it.” Platform-managed certificate issuance can still fail during domain reconnections, registrar migrations, or DNS propagation delays, and a lapsed certificate produces the same customer-facing outage regardless of who was supposed to renew it.
• Setting check intervals aggressive enough to trigger the platform’s own bot protection, producing false-down alerts caused by the monitor itself rather than by any real site problem.

15. Alternatives

• Platform-native monitoring features — Jetpack’s uptime monitoring for WordPress, Shopify’s built-in notification settings, Webflow’s publish-status indicators. Best for a first line of basic awareness, but generally limited to simple uptime signals without keyword assertions, DNS monitoring, or checkout-specific checks.
• CMS-specific management platforms — tools like ManageWP or InfiniteWP for multi-site WordPress management, which bundle basic monitoring with backups, updates, and security scanning. Best for agencies managing many WordPress installations who want monitoring bundled with broader site management.
• General-purpose external synthetic monitoring — WhatPing, UptimeRobot, Better Stack, applied with platform-specific configuration as described throughout this guide. Best for teams wanting a single monitoring tool across mixed-platform portfolios — an agency managing WordPress, Shopify, and Webflow clients simultaneously doesn’t need three separate platform-native tools.
• E-commerce-specific monitoring apps — third-party Shopify App Store tools built specifically around checkout and conversion-funnel monitoring. Best for larger Shopify merchants where checkout monitoring depth matters more than covering other platforms from the same tool.

16. Comparison Text Analysis

Model A: Platform-Native Monitoring Features.

• Setup complexity: minimal — often a toggle within the platform’s existing dashboard.
• Coverage depth: shallow. Typically limited to basic reachability, without keyword assertions, DNS-specific checks, or transactional-flow monitoring.
• Cross-platform consistency: none — an agency or team managing sites across WordPress, Shopify, and Webflow gets three different tools with three different alerting interfaces and no unified view.
• Cost: usually included at no extra charge, since it’s a feature of the platform subscription itself.
• Best fit: a single-site owner on one platform wanting the absolute minimum viable monitoring with zero setup effort.

Model B: General-Purpose External Synthetic Monitoring, Platform-Configured.

• Setup complexity: moderate — requires understanding each platform’s specific failure points, as covered throughout this guide, rather than a single toggle.
• Coverage depth: deep, when configured correctly — DNS assertions, certificate expiry tracking, keyword-based transactional-page checks, and heartbeat monitoring for scheduled or asynchronous processes.
• Cross-platform consistency: high — one dashboard, one alerting configuration, and one API across every site regardless of which platform it runs on, which matters significantly for agencies or teams managing a mixed portfolio.
• Cost: typically a monitoring-specific subscription or usage fee, separate from any platform costs.
• Best fit: any team managing more than a handful of sites, anyone needing checkout- or form-specific monitoring depth that platform-native tools don’t offer, and specifically any agency managing sites across more than one of these three platforms.

The deciding factor for most readers of this guide is portfolio composition: a single WordPress blog with no e-commerce functionality may genuinely be well served by Jetpack’s basic monitoring, while anyone running transactional flows — WooCommerce checkout, Shopify checkout, a Webflow lead-generation form — needs the deeper, platform-configured external monitoring Model B describes, regardless of which specific platform they’re on.

17. Enterprise Deployment

Agencies and larger organizations managing many client sites across these three platforms benefit from provisioning monitors programmatically rather than configuring each one by hand. A script that reads a client roster and creates the appropriate monitor set per platform keeps configuration consistent and makes onboarding a new client a repeatable process rather than a manual checklist:

#!/usr/bin/env bash
set -euo pipefail

CLIENT_DOMAIN="$1"
PLATFORM="$2"  # wordpress, shopify, or webflow

case "$PLATFORM" in
  wordpress)
    curl -s -X POST https://api.whatping.com/v1/monitors \
      -H "Authorization: Bearer $WHATPING_API_KEY" \
      -H "Idempotency-Key: ${CLIENT_DOMAIN}-health-$(date +%s)" \
      -H "content-type: application/json" \
      -d "{\"name\":\"${CLIENT_DOMAIN}-health\",\"type\":\"http\",\"url\":\"https://${CLIENT_DOMAIN}/wp-json/healthcheck/v1/status\",\"interval_seconds\":60}"
    ;;
  shopify|webflow)
    curl -s -X POST https://api.whatping.com/v1/monitors \
      -H "Authorization: Bearer $WHATPING_API_KEY" \
      -H "Idempotency-Key: ${CLIENT_DOMAIN}-dns-$(date +%s)" \
      -H "content-type: application/json" \
      -d "{\"name\":\"${CLIENT_DOMAIN}-dns\",\"type\":\"dns\",\"target\":\"${CLIENT_DOMAIN}\",\"record_type\":\"CNAME\"}"
    ;;
  *)
    echo "Unknown platform: $PLATFORM"
    exit 1
    ;;
esac

curl -s -X POST https://api.whatping.com/v1/monitors \
  -H "Authorization: Bearer $WHATPING_API_KEY" \
  -H "Idempotency-Key: ${CLIENT_DOMAIN}-cert-$(date +%s)" \
  -H "content-type: application/json" \
  -d "{\"name\":\"${CLIENT_DOMAIN}-cert\",\"type\":\"certificate\",\"target\":\"${CLIENT_DOMAIN}\"}"

Every client gets certificate monitoring by default regardless of platform, since an expiring certificate is a universal failure mode, with platform-specific health or DNS checks layered on top.

Governance consideration for agencies specifically. Client offboarding needs to remove monitors as reliably as onboarding creates them — an orphaned monitor for a site whose contract ended continues alerting a team that no longer has any relationship with the client, and eventually gets ignored, which trains the team to ignore alerts generally.

18. Cloud Deployment

For self-hosted WordPress on cloud infrastructure — AWS EC2, GCP Compute Engine, or a managed WordPress host like Kinsta or WP Engine running atop one of those clouds — the underlying cloud firewall still needs to permit inbound traffic from monitoring service IP ranges on ports 80 and 443, following the same Security Group or firewall-rule pattern used for any externally monitored server:

aws ec2 authorize-security-group-ingress \
    --group-id sg-0123456789abcdef0 \
    --protocol tcp \
    --port 443 \
    --cidr 203.0.113.0/24

For Shopify and Webflow, there’s no equivalent cloud firewall to configure on the merchant’s side, since both platforms operate their own infrastructure entirely — the only “cloud deployment” consideration that applies is ensuring the DNS provider hosting the custom domain’s records (which may itself be a cloud provider’s DNS service, like Route 53 or Cloud DNS) is correctly configured with the exact record values each platform requires, and that any DNS-level access controls don’t inadvertently block the monitoring service from resolving the domain during checks.

A multi-region consideration relevant to all three. If a business serves customers across multiple geographic regions, checking from a single monitoring region can miss CDN-edge-specific failures — a CDN node serving one region incorrectly while others function normally. Configuring checks from multiple regions, where the monitoring service supports it, catches this class of regional failure that a single-vantage-point check structurally cannot.

19. FAQs

Q1: Why does my WordPress site’s homepage load fine while checkout is broken?
Answer: WordPress pages are frequently served from cache, and the homepage in particular is the most likely page to be cached and therefore insulated from a PHP error introduced by a plugin update. Checkout pages typically bypass caching because they need to reflect real-time cart state, which means a plugin conflict affecting checkout-specific code paths shows up there first while the cached homepage continues to appear healthy.

Q2: Does Shopify guarantee my custom domain will always work if their platform is up?
Answer: No. Shopify’s uptime guarantees, where offered, generally cover their own infrastructure — the storefront rendering engine, checkout processing, and admin panel — not the DNS configuration or certificate status of a merchant’s custom domain, which remains the merchant’s responsibility to configure and monitor.

Q3: How do I know if a Webflow form is actually delivering submissions?
Answer: A successful-looking submission in the browser only confirms Webflow accepted the form data on its end — it doesn’t confirm the downstream destination, whether that’s Webflow’s native form storage, an email notification, or a third-party webhook integration, actually received it. Monitoring the downstream destination directly, or scheduling periodic test submissions with a distinguishable payload, is the only way to confirm end-to-end delivery.

Q4: Should I monitor every product page on a large Shopify catalog?
Answer: Generally no. Monitoring a representative sample — your highest-traffic or highest-revenue products, plus the cart and checkout flow — catches the vast majority of real incidents without generating check volume large enough to risk triggering the platform’s own automated traffic-shaping measures.

Q5: What’s the right check interval for an e-commerce checkout flow?
Answer: 60 seconds is a reasonable default for a checkout-critical monitor, balanced against most platforms’ rate-limiting tolerance. Faster intervals increase detection speed marginally but raise the risk of the check itself being flagged as abusive automated traffic on shared hosting or heavily protected checkout endpoints.

Q6: Can I monitor WordPress admin login availability without exposing credentials to a monitoring tool?
Answer: Yes — check that /wp-login.php returns its expected login form content via a keyword assertion, which confirms the login page itself is reachable and rendering, without ever attempting an authenticated login through the monitor. This catches server- and page-level failures without the credential-management risk of authenticated monitoring.

Q7: Why did my Webflow site show old content after I published an update?
Answer: This is typically CDN cache behavior, not a monitoring or publishing failure — Webflow serves published content through a content delivery network, and propagation to all edge locations can take a short time after publishing. A content-validation check run immediately after publishing should account for this expected delay rather than treating it as an incident.

Q8: Is DNS monitoring really necessary if I haven’t changed my domain settings recently?
Answer: Yes, because the risk isn’t limited to changes you make deliberately — a domain registrar’s own system change, an expired domain-level auto-renewal setting, or a DNS provider’s infrastructure issue can alter or drop a record without any action on your part, and DNS monitoring is the only way to catch that class of failure before it manifests as a full site outage.

20. References

• WordPress.org Developer Resources (2026). REST API Handbook: Health Check and Status Endpoints. Available at: https://developer.wordpress.org/rest-api/
• Shopify Engineering (2026). Shopify Platform Status. Available at: https://www.shopifystatus.com/
• Webflow University (2026). Custom Domains and DNS Configuration Documentation. Available at: https://university.webflow.com/
• Mockapetris, P. (1987). Domain Names — Concepts and Facilities. RFC 1034. Internet Engineering Task Force (IETF).
• Fielding, R., et al. (2014). Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7231. IETF.
• WhatPing Engineering Documentation (2026). DNS Monitoring and Certificate Monitoring Reference. Available at: https://www.whatping.com/docs/monitors/dns/

21. Conclusion

WordPress, Shopify, and Webflow fail in different places because they’re built differently — one is self-hosted software you’re responsible for end to end, and the other two are fully managed platforms where your monitoring burden concentrates on the domain, certificate, and customization layers you still control. A monitoring setup that treats all three the same way, checking only the homepage for a 200 status code, will miss the checkout failure, the broken form, and the DNS misconfiguration that actually cost you customers — because none of those failures reliably touch the homepage at all.

The fix isn’t more monitoring in the generic sense; it’s monitoring configured against each platform’s specific failure surface: keyword assertions on transactional pages, DNS and certificate checks on custom domains, heartbeat monitoring for anything scheduled or asynchronous, and enough understanding of each platform’s architecture to know which page actually reveals a problem before a customer does. Set that up once per platform, and the difference between a five-minute incident and a five-day one comes down to whether your monitor was watching the right endpoint.

Related Uptime Monitoring Guides

• Website Uptime Monitoring Guide 2026
• E-Commerce Uptime Monitoring
• SSL Certificate Monitoring
• DNS Change Detection
• Uptime Monitoring Check Frequency