Betaatlaswatch

Review GTM health checks, alerts, and signals that need an operator.

Monitor configured GTM accounts, syncs, pages, and operational signals that require attention. Availability depends on enabled data sources and workspace configuration.

Runtime availability depends on the canonical product status, organization entitlement, workspace permissions, deployment configuration, and any provider-specific authorization required by the workflow.

Who it is for

  • Growth and operations teams that need a workspace-scoped review surface for configured tracking, sync, connection, page, checkout, and abnormal-behavior signals.

Codebase contract

  • Application route: /products/atlaswatch
  • Required permissions: atlaswatch.access

How the current workflow works

  1. 1Select an entitled organization and workspace.
  2. 2Open the AtlasWatch dashboard and review open-alert, critical-alert, and health-check counts.
  3. 3Inspect the latest configured checks, including status, severity, observed value, and check time.
  4. 4Review alert history to understand which issues are open, warning, failed, or resolved.
  5. 5Open the AtlasSignals assignment workflow when a canonical signal needs an owner.
  6. 6Review assignment history and route qualified signals into a governed AtlasCampaigns draft when appropriate.
  7. 7Return to AtlasWatch after the underlying source updates and confirm the recorded check or alert state changed as expected.

Current codebase capabilities

  • Workspace-scoped dashboard counts for open alerts, critical alerts, and health checks.
  • Latest configured check table with safe observed values and timestamps.
  • Alert history with severity, status, title, message, and created time.
  • AtlasSignals assignment workflow and ownership history.
  • Governed campaign-play creation from qualified signals.

Current boundaries

  • AtlasWatch reviews stored checks supplied by configured sources; the screen does not itself prove third-party tracking or checkout health.
  • Brand and platform names in stored checks do not imply a live connector is enabled.
  • The product surfaces attention signals but does not autonomously repair integrations or launch campaigns.

Manifest capabilities and permissions

These identifiers are read directly from the canonical frontend product manifest. They describe access boundaries and capability names; they do not by themselves prove provider configuration or runtime availability.

Capabilities

atlaswatch.accessatlaswatch.monitors.runatlaswatch.api.validate_license

Required permissions

atlaswatch.access

What to verify after using it

  • The selected workspace contains only its own checks, alerts, and assignments.
  • Alert and check timestamps correspond to the expected configured source updates.
  • Any campaign play created from a signal still enters the normal governed approval flow.