Monitor uptime, SEO, Shopify cart health and real browser signals from one clean platform.

Site Monitor is a self-hosted monitoring platform for Shopify storefronts and regular public websites. It combines scheduled server-side checks with optional client-side browser signals from the JS Agent.

The key idea is separation: operational health, quality warnings, incidents, browser telemetry and accepted muted findings are shown as different layers instead of one noisy status.

• Use it to monitor storefront availability, important pages, SEO signals, Shopify cart functionality, product/collection rules and real browser-side errors.
• Use the global site filter to focus the admin panel on one property.
• Use pagination, filters and cleanup tools to keep historical data usable as the database grows.
• Public documentation explains usage only. Server paths, cron commands, private tokens and internal installation details belong in the future owner-only admin documentation area.

The Dashboard is the fast operational overview. It answers whether monitored sites are currently healthy, whether open incidents exist and what recent check runs look like.

Operational health is separated from quality warnings. A store can be operationally OK while still having SEO or quality findings that should be reviewed.

• Site cards summarize operational status and quality warning counts.
• Recent runs show the latest check executions without replacing the full Runs section.
• Open incidents show active problems that still need attention.
• The global site selector limits Dashboard numbers to one selected site when needed.

A Site is a monitored property. It can be a Shopify storefront or a generic website. The Sites section controls the base URL, platform type, active state, default intervals and JS Agent behavior.

When a site is selected globally, most admin sections show only that site. This makes troubleshooting easier when several stores are connected.

• Name: the readable site name used throughout the admin panel.
• Base URL: the canonical website address used by checks and host validation.
• Platform: Shopify enables Shopify-specific checks; Generic keeps the site focused on normal website monitoring.
• Active/Paused: active sites participate in monitoring; paused sites can remain configured without creating noise.
• Default interval: suggested schedule used when creating new checks for the site.
• Site key: unique key used by the JS Agent snippet to attach browser events to the correct site.
• Agent last seen: confirms whether the JS Agent has recently reported from real browsers.
• Operational Health: reflects critical checks only.
• Quality: counts active non-muted quality findings such as SEO or content issues.

Site settings define what the system knows about a property before individual checks are created. They also decide how much browser-side data is collected by the JS Agent.

For Shopify stores, the base URL should match the public storefront domain where the JS Agent will run. This allows host validation to reject events sent with the wrong site key.

• Agent enabled: allows the site to receive browser-side events from the JS Agent.
• Collect title/meta/canonical/robots: controls which SEO signals the browser agent records.
• Collect browser performance: stores timing values such as total load, TTFB, DOM ready and load event.
• Collect JS errors: records browser JavaScript errors and resource load failures when available.
• Check /cart.js from browser: performs a safe read-only GET request to the Shopify cart endpoint; it does not add or remove cart items.
• Collect full URL/query: stores the full page URL. Keep sanitization enabled to remove sensitive parameters.
• Sampling rate: controls what percentage of pageviews are reported to reduce database growth on high-traffic sites.
• Max JS errors stored: limits how many errors are attached to one browser event.
• Agent retention days: determines how long browser events should be kept before cleanup.
• Store full raw agent payload: should normally stay off to keep database usage compact.

A Check is a monitoring rule attached to one site. It defines what should be tested, how often, how strict the result should be and how the result affects health.

Checks create Runs. Repeated failures can create Incidents. Specific findings inside a check can be muted without muting the full check.

• Name: internal label, for example Homepage, Homepage SEO, Cart add simulation or JS Agent heartbeat.
• Site: the monitored property this check belongs to.
• Type: determines the monitor logic that will run.
• Target URL or target data: URL, Shopify variant, product JSON, collection JSON or site-level heartbeat target depending on type.
• Interval: how often the check should run when the worker is active.
• Timeout: maximum time allowed before the check is considered failed or incomplete.
• Expected status: the HTTP code expected for normal page checks, usually 200.
• Must contain: optional text that must be found in the page HTML; if missing, the run is marked as a problem.
• Must NOT contain: optional text that must not be found in the page HTML; if present, the run is marked as a problem.
• Health impact: decides whether problems affect operational health, quality counts, info history or are muted.
• Active: inactive checks stay saved but are not scheduled.

Different check types are used for different levels of confidence. Server-side checks prove what the monitor server sees. JS Agent checks prove that real browsers are reporting. Shopify checks verify storefront-specific behavior.

Use a small number of critical checks for availability and cart health, then add quality checks for SEO, products and collections.

• HTTP / Page: validates status code, response time, redirects and optional expected/unexpected text.
• SEO: inspects title, meta description, canonical, robots/noindex and H1 signals. Findings are structured so they can be muted individually.
• Shopify cart simulation: tests add-to-cart safely from the monitor server with an isolated session and configured variant ID.
• Shopify product rules: validates product JSON, required/forbidden tags, availability and image requirements when configured.
• Shopify collection rules: checks collection JSON and can detect empty or underpopulated collections.
• Client agent heartbeat: checks whether the JS Agent has recently sent events for the site.

Health impact controls how a check affects the system. This prevents SEO warnings from looking like downtime and prevents informational checks from opening incidents.

Changing impact affects the whole check. To hide only one specific repeated error, use Muted findings instead.

• Operational / Critical: affects the main site health and can open incidents. Use for uptime, essential pages, cart simulation and critical JS Agent heartbeat.
• Quality warning: counts as quality, not downtime. Use for SEO, content, product rules, collection rules and image quality.
• Info only: stores history without warning counts or incidents.
• Muted: keeps the check saved but avoids health noise. Use carefully because it applies to the entire check.

Runs are the historical evidence of every check execution. They show when the check ran, what status it returned, response time, HTTP code, active findings, muted findings and a response excerpt when available.

Runs support filtering and pagination. Per-page preferences are saved per user for each section.

• Use filters by site, check, status, search text and date range.
• Active findings affect status and can be muted when they are accepted for the selected scope.
• Muted findings remain visible as audit information but do not affect status.
• Delete filtered runs removes matching history records.
• Reset filtered runs removes matching history and clears last status metadata for affected checks.

Incidents represent problems that need attention. They are separate from raw check runs so the team can focus on active issues instead of every historical warning.

Closed incidents do not affect the main dashboard. If the underlying problem appears again and is not muted, the system can open a new incident later.

• Open incidents are active issues.
• Closed incidents remain as history.
• Close/reset filtered incidents removes matching incidents from the active queue while keeping history.
• Delete filtered incidents permanently removes matching incident records.
• Muted findings should be used for accepted repeated issues so incidents do not reopen for the same finding.

The JS Agent is a lightweight browser-side script installed on a monitored website. It reports what real visitors experience, including browser timing, client-side SEO signals and JavaScript errors.

The agent is designed to be read-only. It does not change the page, does not inject UI, does not add items to cart, does not remove items from cart and does not start checkout.

• Reports page title, meta description, canonical and robots signals when enabled.
• Reports total load time, TTFB, DOM ready and load event timing when enabled.
• Reports JavaScript errors and resource load errors when the browser exposes details.
• Safely checks /cart.js with a GET request on Shopify sites when enabled.
• Uses the site key to attach events to the correct site and host validation to reject wrong-key events.
• Supports retention and compact storage settings to keep database growth manageable.

Muted findings are specific accepted errors. They are more precise than muting an entire check. A muted finding no longer affects health, quality counts, incidents or alerts, but it remains visible in run details as audit information.

Example: mute Missing H1 only for Candy Catz / Homepage SEO. The same check can still warn later for canonical mismatch, noindex or missing meta description.

• Use Mute for this check from a Run active finding when one issue is accepted.
• Review all mute rules in the Muted findings section.
• Remove a mute rule when the issue should become active again.
• Muted findings are excluded from Site quality warnings and Dashboard warning counts.
• Older run rows remain historical; future runs apply the mute rule.

Shopify sites can use normal website checks plus Shopify-specific behavior checks. The goal is to catch storefront problems without installing heavy monitoring apps inside Shopify.

Cart simulation is intentionally server-side. The JS Agent should observe real browser signals passively, not manipulate visitor carts.

• Cart add simulation: configure a valid available variant ID and test whether the storefront can add it to a temporary cart session.
• Product rules: check tags, forbidden tags, availability and image requirements where configured.
• Collection rules: detect empty collections or collection JSON issues.
• SEO checks: apply to homepage, product pages, collection pages, content pages and landing pages.
• JS Agent: detects real browser-side errors, performance and safe cart endpoint availability.

Users are managed inside the protected monitor app. Roles define what each person can see or change. Public visitors cannot access internal data without an account.

• Admin: management access for assigned workspaces and sites.
• Manager: manage sites, checks, alerts and incidents where allowed.
• Operator: view, run checks and close incidents.
• Viewer: read-only access.

Monitoring systems generate data continuously. Cleanup tools keep Runs, Incidents and JS Agent events manageable while preserving what matters.

Cleanup actions should be used with filters. Delete removes records. Reset removes records and also clears related current-state metadata where applicable.

• Runs cleanup: delete history or reset matching run data and affected check last statuses.
• Incident cleanup: close/reset filtered incidents or delete test/noise records permanently.
• JS Agent cleanup: delete filtered events, prune old events by retention policy and optimize the table.
• Use retention settings per site to prevent browser events from growing indefinitely.

Start small. Create a site, add critical HTTP checks, add one SEO check, configure JS Agent only when you want browser telemetry, then add Shopify-specific rules where needed.

After a few days of data, tune impact levels and mute accepted findings. This makes the system useful without becoming noisy.

• Add site and confirm the base URL is correct.
• Add homepage HTTP check as Operational.
• Add homepage SEO check as Quality.
• For Shopify, add cart simulation with a safe available variant ID.
• Install JS Agent and confirm heartbeat if browser telemetry is desired.
• Review Runs, mute accepted findings and leave important problems active.
• Enable alerts after the signal is clean.

This section answers common usage questions without exposing private server configuration or installation details.

For protected operational documentation, use the future owner-only admin documentation area.

• Does the JS Agent change the site? No. It is read-only in the current design.
• Does the JS Agent add items to cart? No. It only performs safe read-only checks such as /cart.js when enabled.
• Why can a site be OK but have quality warnings? Because uptime and SEO/content quality are separate layers.
• Should I mute an entire check or one finding? Mute one finding when only one specific issue is accepted.
• Why do older Runs still show warnings after a mute? They are historical. Future runs apply the mute rule.