Data Watcher Bundle Laravel Package

Product Decisions This Supports

• Data quality as a first-class product surface. A database anomaly watcher turns "we think the numbers are right" into a monitored, alertable signal. That supports decisions about whether data trust is a feature we invest in (dashboards, freshness SLAs, incident runbooks) or a support-cost we absorb.
• Build vs. buy for internal monitoring. The bundle covers a narrow but real slice — scheduled SQL checks against Doctrine connections, email notification, execution history. If the alternative is an internal "cron + script + Slack webhook" tool maintained by one engineer, this is a credible buy/skip-building candidate for the first iteration; if the alternative is a full observability platform (dbt tests, Monte Carlo, Great Expectations), this is a stopgap, not a replacement.
• Roadmap input for existing Symfony products. For teams running Symfony 6.3–8.0 with Doctrine, this is low-friction triage for revenue-relevant data: order counts, ledger balances, orphaned foreign keys, stale rows. That directly informs whether the next sprint goes to feature work or to a "we have silent data drift" remediation epic.
• Incident prevention vs. incident response. Execution history plus scheduled checks shift the org from reactive (customer reports a bad report) to proactive (alert fires before the monthly close). Useful when prioritising on-call load reduction.
• Use case scoping: good fit for reconciliation checks, nightly sanity sweeps, freshness/staleness detection, referential-integrity drift, and row-count deltas; poor fit for real-time streaming validation or ML-based anomaly detection.

Adoption caveat that shapes the decision: the README targets Symfony, not Laravel. If the product is Laravel-based, this package is not a drop-in — choosing it means either adopting Symfony conventions in a subservice or porting the concept. That reframes the decision from "install a package" to "build a small internal service or vendor a different tool."

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony 6.3 / 7.0 / 8.0 on PHP ≥ 8.2 with Doctrine DBAL (and optionally ORM).
• You already run Messenger + Scheduler + Mailer + Twig — the bundle assumes all four, so the marginal infrastructure cost is near zero. Without Scheduler, you inherit setup work.
• The need is scheduled, rule-based checks with email alerts and an audit trail — not dashboards, not anomaly ML, not multi-tenant alert routing.
• You can accept source-only distribution: installation requires a repositories VCS entry and composer require, because it is not (per the README) published on Packagist. That has real consequences for CI caching, dependency pinning, and security scanning.
• Your team is comfortable with a single-maintainer, pre-1.0-shaped dependency — 2 stars, 0 dependents, one author.

Look elsewhere when:

• You're on Laravel. Different framework contract entirely; the concepts port, the code doesn't.
• You need governed alerting — routing rules, deduplication, escalation, on-call integration (PagerDuty/Opsgenie), suppression windows. Email-to-recipients is the whole notification story here.
• You need a vendor with an SLA, security review, or CVE process. Zero dependents and a VCS-only install mean your supply-chain review has nothing to lean on.
• Compliance or data-residency constraints make an unreviewed third-party bundle in the query path unacceptable.
• Your anomaly needs are statistical or high-volume — this is rule-based checking, and it will not scale to wide-scan or per-event validation workloads.
• You want zero-ops. You will own the failure modes: a broken cron expression, a mailer outage, or a check that silently stops running (note: execution history helps here, but absence of execution may not alert by default — validate this).

Mitigation if you do adopt: fork and pin to a commit SHA, wrap the bundle behind a thin internal interface so checks are defined in your code, and treat the email channel as one of several sinks you may need to replace.

How to Pitch It (Stakeholders)

For executives (30 seconds): "We have a recurring class of problem where the product is technically 'up' but the data behind it is wrong — stale pricing, missing orders, broken references — and we find out from customers or from the monthly close. This package is a small, free monitoring layer that runs scheduled SQL checks and emails the team the moment a rule trips, with a history of every run. It reuses infrastructure we already run in our Symfony services, so the cost to trial is days, not a quarter. It is not an enterprise data-observability platform and it's maintained by a single author — so we should treat it as a fast, cheap first step that buys us a quarter of learning, with a fork-and-pin policy so we're never blocked."

For engineering:

• It's a Symfony bundle, not Laravel — confirm stack fit before anything else.
• Dependencies are all standard: framework-bundle, messenger, mailer, twig-bundle, scheduler, doctrine/dbal, cron-expression. Marginal infra cost is low; the risk is maturity, not integration.
• Install is via VCS repositories entry, not Packagist. Plan for a pinned commit, a fork, and a note in the dependency inventory.
• Define checks in application code behind an internal abstraction so that replacing the alerting transport (email → Slack/PagerDuty) or the whole bundle later is a contained change.
• Validate the two silent-failure paths before trusting it: what happens when a check stops running, and what happens when the mailer fails. Execution history is the right primitive here — confirm it's sufficient to alert on gap, not just on result.

Recommended next step: a two-week, one-service spike covering 3–5 high-value checks on revenue- or compliance-critical tables, with an explicit go/no-go gate: does it catch a real issue, and does it stay quiet otherwise?