Automated reports and delivery

Dashloom turns any of its five analysis agents into an on-demand or recurring report. Each report points to one stored analysis run, so the summary, findings, model usage, and frozen evidence remain auditable together.

Proactive Agent alerts

The Reports page monitors normalized metrics by absolute value or daily percentage change. Detection itself is deterministic, observes the configured cooldown, and creates an auditable report whenever a rule matches.

Each rule may optionally assign one of the five specialist Agents. Dashloom checks model and evidence readiness inside the rule's product scope before enabling it, spends the workspace's normal AI allowance only after a deterministic match, and locks the explanation to that same scope. If the model, quota, or analysis fails, the original alert remains valid and deliverable; the run history exposes a stable Agent status and public error code without storing raw provider errors.

Selected channels reuse the encrypted, SSRF-protected delivery path. A channel response marked as failed is treated as a failed alert delivery and retried on a later evaluation instead of being reported as successful. Rules can be paused and resumed; resume repeats the channel and Agent readiness checks.

Generate a report

1. Connect and synchronize at least one data source.
2. Configure a validated AI provider from Agent or Settings.
3. Open Reports, choose all products or one real product, choose an Agent and period, then select Generate report.

Dashloom evaluates readiness separately for every product-and-Agent pair using recent matching first-party and competitor evidence. Specialists without supported evidence in the selected scope are labeled and disabled. The API verifies that the product belongs to the active workspace and freezes the scope into both the Agent run and report history.

The Community edition uses your provider key. Managed providers use the workspace plan's server-side daily allowance and append an immutable usage event after a successful model call.

Connect delivery

Slack and Discord use incoming webhook URLs. Telegram uses a Bot Token and numeric Chat ID; Dashloom constructs the fixed api.telegram.org endpoint and sends a bounded sendMessage payload. A generic webhook receives a dashloom.report.ready JSON event. Email delivery expects an HTTPS mail-relay webhook that accepts to, subject, and text fields; this keeps Dashloom independent of a single email vendor.

Delivery configuration is encrypted. URLs must use HTTPS and cannot target loopback, private, link-local, metadata, or reserved hosts. A report/channel pair has one delivery ledger entry; retrying a delivered pair is a no-op, while failed attempts increment their retry counter.

Schedule reports

Create a daily, weekly, or monthly schedule with a portfolio or real-product scope, an IANA timezone, local delivery hour, optional channel, and either one specialist or an Executive Brief with two to five specialists. Cloudflare Cron checks due schedules every 15 minutes. The scope is server-persisted and reused for every specialist and retry. Deleting a product removes its future schedules rather than silently widening them; generated reports and briefs retain that they were product scoped. A schedule occurrence uses an idempotency key based on the schedule ID and planned time, preventing duplicate reports after retries.

Each schedule exposes its last attempt, operational status, stable error category, and consecutive failure count. Owners and administrators can pause, resume, or delete it without deleting reports already generated. A failed occurrence freezes its original occurrence identity, retries the same report after 15 minutes, and uses bounded exponential backoff up to six hours; a delivery retry therefore does not spend another model call. Raw provider and delivery errors are not persisted in schedule health or automation summaries. Any failed occurrence also marks the outer Cron task as failed instead of producing a false-success automation run. Resuming repeats evidence and model readiness checks before a new run time is calculated.

The Agent comparison window matches the cadence: daily reports compare the last completed day with the day before it, weekly reports compare the last completed seven days with the preceding seven days, and monthly reports compare the last completed 30 days with the preceding 30 days. Using completed periods prevents a few hours of the current day from being compared with a full prior period. Frozen evidence records the exact dates. If a bounded collection limit is exceeded, the run is marked incomplete and the validated Agent output must disclose partial coverage.

Run a synchronization after upgrading from an earlier Dashloom release so connected sources backfill the full monthly comparison window before the first monthly report.

Set this additional secret even though scheduled events call the job directly; it protects the authenticated maintenance endpoint:

npx wrangler secret put REPORT_CRON_SECRET

Self-hosters using another scheduler may send POST /api/cron/reports with Authorization: Bearer <REPORT_CRON_SECRET>.

For production, apply and verify all D1 migrations remotely before deploying the Worker. Confirm that report_schedules, reports, and agent_executive_briefs contain scope_mode and product_id; verify the product foreign-key delete behavior and scope indexes; then confirm that no migration is pending.