WPHammer
Log in
  • Notifications
  • Incidents
  • SSL certificate monitoring
  • Daily aggregation
  • Data retention
  • Configuring uptime monitoring
  • Related

    • Uptime Monitoring

    WPHammer continuously checks your WordPress sites over HTTP and tracks availability, response times, and SSL certificate status. When a site goes down, you get notified. When it recovers, you get notified again. Everything in between is recorded so you can review uptime history and spot patterns.

    How uptime checks work

    Each site with uptime enabled has an UptimeConfig record that controls check behavior. On a schedule, the DispatchUptimeChecksCommand finds all configs with a next_check_at in the past and dispatches a PerformUptimeCheckJob for each.

    The job makes an HTTP request to the site URL with a 10-second timeout and 5-second connect timeout. It records the response as an UptimeCheck with the status code, response time in milliseconds, and whether the check was successful. A check is considered successful if the HTTP status is in the 200–299 range. If include_redirects is enabled on the config, 300–399 responses also count as successful.

    To avoid overwhelming DNS resolvers, jobs are staggered — dispatched with a 2-second delay for every batch of 5 checks.

    Status tracking

    Each site's uptime config tracks a current_status using the UptimeStatus enum:

    • Up — the site is responding normally
    • Degraded — the site is responding but slowly (above the configured slow_threshold_ms)
    • Redirected — the site is returning a redirect and include_redirects is disabled
    • Down — the site has failed multiple consecutive checks
    • Unknown — no checks have been performed yet

    Confirmation thresholds

    A single failed check does not immediately mark a site as down. The EvaluateUptimeStatusAction requires a configurable number of consecutive failures (the confirmation_threshold) before transitioning to Down status. This prevents transient network blips from triggering false alerts.

    Recovery works similarly — 3 consecutive successful checks are required before a site transitions from Down back to Up.

    For degraded status, 3 consecutive slow responses (above slow_threshold_ms) trigger a transition to Degraded, and 3 consecutive normal-speed responses restore it to Up.

    Adaptive check intervals

    While a site is healthy, checks run at the configured check_interval_minutes. When a site is being confirmed as down, the interval drops to 30 seconds. While actively down or recovering, checks run every minute to detect recovery quickly.

    Notifications

    WPHammer sends notifications at key status transitions:

    • SiteDownNotification — sent when a site transitions to Down status after exceeding the confirmation threshold
    • SiteRecoveredNotification — sent when a previously down site returns to Up status

    While a site remains down, re-notifications are sent every 30 minutes so the issue stays visible.

    Incidents

    When a site goes down, WPHammer creates an UptimeIncident record that tracks:

    • When the incident started
    • When it was resolved (if applicable)
    • Total downtime in minutes
    • Number of failed checks during the incident
    • The last status code and error message received

    Open incidents are visible on the site detail page and surface on the dashboard.

    SSL certificate monitoring

    The CheckSslCertificateAction runs alongside uptime checks but at most once every 24 hours. It connects to the site via a stream socket, extracts the SSL certificate, and records:

    • Expiry date (ssl_expires_at) — used to calculate days remaining
    • Issuer (ssl_issuer) — the certificate authority

    You can check remaining days via the sslDaysRemaining() method on UptimeConfig. SSL data also feeds into the Domains & SSL monitoring.

    Daily aggregation

    Individual UptimeCheck records are aggregated daily by the AggregateUptimeDailySummariesCommand. Each UptimeDailySummary stores:

    • Total checks and successful checks for the day
    • Average, minimum, and maximum response times

    The uptimePercentage() method on UptimeConfig uses these summaries for historical periods and raw checks for the current day, giving you an accurate uptime percentage over any time window.

    Data retention

    Raw UptimeCheck records are pruned by the PruneUptimeChecksCommand based on each config's retention_days setting. Records are deleted in batches of 1,000 to avoid memory pressure. Daily summaries are kept indefinitely since they are already compact aggregations.

    Configuring uptime monitoring

    Uptime monitoring is configured per site. Key settings on UptimeConfig:

    Setting Description
    is_active Enable or disable monitoring for this site
    check_interval_minutes How often to check (default varies)
    confirmation_threshold Consecutive failures before marking down
    include_redirects Whether 3xx responses count as successful
    slow_threshold_ms Response time threshold for degraded status
    retention_days How long to keep raw check records

    Related