Pulse — findings & savings

Pulse runs scheduled, read-only scans of your connected infrastructure and turns what it sees into findings and recommendations. Nothing is executed; every finding is backed by data returned from your integrations.

The lifecycle

Status	Meaning
open	Newly detected, awaiting review
acknowledged	Seen by the team, on the list
in_progress	Someone is working it
resolved	Fixed and verified — the timestamp feeds your MTTR and value metrics
dismissed	Deliberately declined (not deleted; kept for the record)

A finding reaches resolved three ways: your team marks it, the resolution wizard verifies the fix against your live environment, or the reinvestigation sweep (below) re-checks a stale finding and confirms with evidence that the issue is gone. Every resolution records who or what resolved it and on what evidence.

Recommendations attached to findings carry their own status (pending → in_progress → completed / dismissed). Approving a recommendation from the Morning Report marks it completed.

Findings carry a severity (critical … info) and a domain (FinOps, security, SRE, topology). Duplicate detections are clustered automatically so the same underlying issue isn't counted twice.

How savings figures work

DXDT is deliberately conservative with money numbers:

• Identified — the estimated monthly savings on a grounded finding, summed over unique resources (overlapping findings never double-count a resource).
• Actioned — identified savings on resolved findings, whether your team resolved them or a verification agent confirmed the fix.
• Realized — reported only once confirmed against your actual cloud bill. If you don't see a realized figure, it's because DXDT won't estimate one.

Working with findings

• Web: the Pulse dashboard — filter by domain, severity, status; open a finding for its evidence trail (every investigation step is recorded). Findings that aren't yet resolved offer Guided Resolve — a step-by-step, evidence-cited resolution wizard that verifies each step and re-runs the original detection to confirm the fix.
• CLI: dxdt pulse findings --status open, --json for scripting.
• Schedules: agents run daily by default; per-agent schedules are configurable per tenant.

The Resolved view

The Resolved tab shows closed findings per cluster: how many times the issue was seen, what resolved it (a team member, the reinvestigation agent, or the sweep), the resolution evidence, and the agent's reasoning. A Reopen control puts a finding back in the open list if the issue returns. Scripting: GET /api/v1/pulse/resolved?domain= or dxdt pulse resolved.

The reinvestigation sweep

Findings that go stale — no fresh sighting in their cluster for 14 days — are re-verified automatically by a recurring sweep: the highest-severity / highest-savings items are re-checked individually, and the long tail is verified in small batches. The sweep never closes a finding on silence: a finding is only marked resolved on positive evidence that the issue is gone, and that evidence is stored on the finding. Anything unverifiable stays open and is simply marked as re-checked.

What Pulse won't flag

Scans stay inside your tenant's world: findings about DXDT's own scanner identity are filtered out, and a permissions gap in your cloud account surfaces as a single low-severity onboarding finding asking for read access — not as a list of security findings.

Routing findings to owners

Findings are most useful in front of the team that owns the resource. Team page → Features → Finding routing (admins): add rules that match against a finding's title, description and resources — e.g. match payments → #payments-oncall. New findings that match are delivered directly to that Slack channel (and optional email recipients) as a grouped alert with severities and estimated savings, in addition to your default channels.

Best practices

• Work the statuses. Resolving and dismissing findings is not housekeeping — it's what keeps your savings and MTTR numbers true, and it teaches Pulse what your team considers noise.
• Teach instead of re-dismissing. If Pulse keeps flagging something your team knows is expected ("the staging DB fails over every Sunday"), teach DXDT the fact once — scans take taught facts into account.
• Watch quick wins. Findings marked quick_win effort are the fastest route to actioned savings.