TruGreen Automation Dashboard

Checks: Confirms that key pages load and core site experiences are available before deeper testing begins.

Protects: This protects basic site health and provides an early release-confidence signal across the highest-value user journeys.

Review: If smoke fails, review the first broken page or assertion, confirm whether the issue is environment-specific, and route it to the owning dev or QA contact before relying on downstream suite results.

Checks: Runs automated accessibility checks to highlight violations, recurring patterns, and shared component-level issues.

Protects: This helps the team catch accessibility regressions early and compare recurring issues across releases and environments.

Review: Review the common issues view first, identify whether findings are new or recurring, and confirm whether the issue should be fixed in a shared component, content template, or page-specific implementation.

Checks: Validates whether critical analytics events fire with the expected tracking configuration.

Protects: This protects reporting integrity, analytics QA signoff, and confidence that releases do not break measurement.

Review: If analytics checks fail, confirm whether the event is missing, delayed, or misconfigured, then involve the dev or analytics owner with the failing report and affected tracking details.

Checks: Checks whether key service endpoints respond successfully and return expected data for monitored scenarios.

Protects: This protects integration reliability and helps catch service-side issues that may not be obvious from UI behavior alone.

Review: If an API check fails, confirm the response status and payload behavior first, then determine whether the problem belongs to the upstream service, environment configuration, or downstream site dependency.

Checks: Tracks Lighthouse-based performance results over time to show lab-measured speed and stability trends.

Protects: This helps the team spot regressions in loading and rendering behavior before they become visible customer experience issues.

Review: Review metric-level changes before focusing on the overall score, confirm whether the regression is lab-only or likely user-facing, and compare recent runs before escalating.

Checks: Compares current screenshots to approved baselines to detect layout, styling, and rendering changes.

Protects: This protects presentation quality on customer-facing pages and helps separate intended UI changes from unexpected regressions.

Review: If a visual diff appears, check whether the change matches an expected release update, then decide whether to accept a new baseline or raise a defect for unintended UI drift.

Checks: Runs visual snapshot checks against Storybook stories tagged for test coverage to catch component-level UI drift.

Protects: This protects shared UI building blocks before regressions spread into full pages and customer journeys.

Review: If a Storybook diff appears, compare it to the intended component change first, then decide whether to update the baseline or open a defect for unintended visual drift.

Checks: Exercises key steps in selected user flows (buy-online-e) to verify that users can move through important journeys without major blockers.

Protects: This protects high-value business paths tied directly to conversion, revenue, or other strategic goals.

Review: If a flow fails, identify the earliest blocked step, confirm business impact, and route it quickly because conversion-path failures usually need same-day triage. As more flows are added, review each for its specific business impact.

Checks: Checks for broken or unreachable links so the team can spot navigation and destination issues early.

Protects: This protects content quality, SEO-sensitive paths, and customer trust when moving through the site.

Review: When enabled, review failures for repeated patterns first, separate blocked third-party destinations from real site defects, and prioritize broken customer-path links for follow-up.