1. 1
   Log in to DPSMF

   Navigate to your DPSMF URL and log in with your admin credentials. First-time users will be prompted to set a password on initial login.
2. 2
   Open Instance Manager

   Go to Settings → Instances → Add Instance. Enter the SQL Server hostname or IP address, port (default 1433), and credentials. SQL Auth and Windows Auth are both supported.
3. 3
   Test the Connection

   Click Test Connection. DPSMF will verify connectivity and permissions. A green check confirms the instance is reachable and the monitoring account has the required permissions.
4. 4
   Baseline Learning Period (7 Days)

   DPSMF observes silently for the first 7 days, building statistical baselines for every query hash, wait type, and resource metric. No alerts fire during this period — this is expected behaviour.
5. 5
   Alerts Go Live on Day 8

   From day 8, any deviation beyond 3σ from the learned baseline triggers an alert. The longer DPSMF runs, the sharper the baselines become. False positive rates typically drop below 6% after 30 days.

1. 1
   Open the Trial Form

   Click Start Free Trial on the Pricing page or navigate directly to dpsmf.ai/trial.html. No credit card is required.
2. 2
   Fill in Your Details

   Enter your full name, work email address, organisation name, and choose a tier from the dropdown. Create a password of at least 8 characters.
3. 3
   Submit and Save Your License Key

   On success the page displays your DPSMF-XXXXXX-XXXXXX-TRIAL license key. Copy it immediately — it is also emailed to you, but the email may take a few minutes to arrive. You will need the key on first login.

1. 1
   Navigate to Login

   Go to dpsmf.ai/dpsmf-login.html or click Log In from any DPSMF page. Enter the email and password you registered with.
2. 2
   Activate Your License Key

   After login, if your account does not yet have an active license you will see the License Activation prompt. Paste your DPSMF-XXXXXX-XXXXXX-TRIAL key and click Activate. The key is validated server-side and tied to your account — it cannot be used again.
3. 3
   Land on the Dashboard

   After activation you are taken to the main dashboard at /app/. The dashboard is initially empty — no instances are connected yet. The trial countdown begins at this point.

1. 1
   Open Instance Manager

   From the dashboard, click Instances in the left sidebar, then click + Add Instance. Alternatively go to Settings → Instances → Add.
2. 2
   Enter Connection Details

   Fill in: Instance Name (display label), Server Host (hostname or IP), Port (default 1433), SQL Server Version (2016–2025 or Azure SQL). Select authentication: SQL Auth (username + password) or Windows Auth (service account via Kerberos).
3. 3
   Verify Connectivity

   Click Test Connection. DPSMF will attempt a lightweight DMV query (SELECT @@VERSION) to confirm network and credentials. Common failures: firewall blocking port 1433, incorrect hostname, login not mapped to a database. See Requirements for the full permission list.
4. 4
   Select Databases to Monitor

   After a successful test, DPSMF lists all databases on the instance. Choose which ones to include in per-DB monitoring. System databases (master, tempdb, msdb) are always included for wait-stat and config analysis.
5. 5
   Save and Begin Collection

   Click Save Instance. DPSMF begins polling immediately at 15-second intervals for wait stats, DMVs, and execution plans. The instance card on the dashboard shows a green Live badge within 30 seconds.

DPSMF does not generate recommendations immediately. The Intelligence Engine needs to observe a representative sample of workload patterns — typically one full business day — before the Knowledge Graph can distinguish normal from anomalous behaviour.

During the baseline period you can still use Sentinel in Query Mode — ask questions like "What are my top wait types right now?" or "Show me execution plans for queries over 5 seconds." These are answered directly from live DMV data without requiring a trained baseline.

After the baseline window closes, Anomaly Detection activates and the alert system comes fully online. Here is what to expect on Day 2:

1. 1
   Dashboard Alert Cards Appear

   The dashboard shows active alerts sorted by severity (Critical → Warning → Info). Each card shows the affected instance, the alert type, and a one-line Sentinel summary. Click any card to open Sentinel with the alert pre-loaded into context.
2. 2
   Open Sentinel for Root-Cause Analysis

   Sentinel displays its evidence chain: the triggering metric, correlated wait types, execution plans, and Knowledge Graph context nodes. Click Explain to get a plain-English explanation. Click Recommend to see prioritised remediation steps with confidence scores.
3. 3
   Configure Notification Channels

   Go to Settings → Notifications to add email, Microsoft Teams webhook, or SMS recipients. During a trial, alert emails are sent from alerts@dpsmf.ai. Add this address to your allowlist to avoid spam filtering.
4. 4
   Create Your First Runbook

   When Sentinel recommends a remediation step you want to formalise, click Save as Runbook. The runbook captures the evidence chain, the recommendation, and any notes you add — creating an institutional knowledge record that persists beyond your trial.

Sentinel is the primary monitoring view in DPSMF. It shows a live feed of all connected instances, current health scores, active alerts, and real-time metric sparklines — all updated every 10 seconds.

The SN1 live feed delivers a sub-second stream of metric events, alert state changes, and anomaly detections via server-sent events. It powers the real-time indicators on Sentinel tiles.

Individual Sentinel features (anomaly overlay, AG health panel, capacity widgets) can be enabled or disabled per-user by an admin under Settings → Sentinel Features. This allows feature rollout to be controlled without a code deployment.

DPSMF collects instance-level metrics by default. Per-database monitoring extends this to track transaction log usage, index health, active query load, and alert thresholds individually per database — so a single busy reporting database does not mask the health of other databases on the same instance.

The AG Monitor tracks all Availability Groups on connected instances. It polls sys.dm_hadr_availability_group_states, sys.dm_hadr_database_replica_states, and sys.dm_hadr_availability_replica_states every 10 seconds.

1. 1
   Alert Fires

   A metric breaches its 3σ threshold (or a configured static threshold). The alert appears in the live feed with severity: Info, Warning, or Critical.
2. 2
   Acknowledge

   Click Acknowledge to indicate the alert has been seen. An unacknowledged alert will escalate to email after 60 minutes.
3. 3
   L2 Escalation

   If still unacknowledged after 120 minutes, the alert escalates to L2 with an urgent email. The alert manager shows an escalation badge.
4. 4
   Resolve

   Once the underlying condition clears, click Resolve and optionally add a resolution note. Resolved alerts are archived and contribute to the knowledge graph for future pattern matching.

Each alert opens a detail view showing the metric timeline, the anomaly score at the time of firing, correlated events within ±30 minutes, and AI-generated root cause analysis with a specific recommended action.

1. 1
   Go to Settings → Policies

   All active policies are listed here with their scope (instance, database, or global) and current status.
2. 2
   Choose Policy Type

   Select Baseline (fires when deviation exceeds Nσ), Threshold (fires when metric exceeds a fixed value), or Absence (fires if a metric stops being collected).
3. 3
   Set Scope

   Scope the policy to a specific instance, a specific database, or apply it globally across all monitored instances.
4. 4
   Configure Severity & Suppression

   Set the severity (Info / Warning / Critical) and optionally configure a suppression window (e.g., suppress between 01:00–05:00 during maintenance windows).

DPSMF enforces license-level policy limits. Monitor tier allows up to 10 active policies per instance. Intelligence and Enterprise tiers are unlimited. Policy checks are evaluated before every alert fires — a suppressed policy will not alert even if the condition is met.

A runbook is a structured set of steps that appears automatically when a specific alert type fires. Instead of DBA tribal knowledge living in someone's head, runbooks encode the correct response procedure and make it instantly available to any engineer on call.

1. 1
   Go to Settings → Runbooks → New Runbook

   Give the runbook a name and description. Choose which alert type(s) it attaches to (e.g., all blocking_count critical alerts).
2. 2
   Add Steps

   Each step has a title, detail text, and an optional verification query — a read-only T-SQL query that the engineer can run to confirm the condition before and after applying a fix.
3. 3
   Set Escalation Path

   If the runbook steps don’t resolve the issue, configure the escalation contact (name, email, phone) shown at the bottom of the runbook view.
4. 4
   Activate

   Toggle the runbook to Active. It will now appear automatically in the alert detail view whenever a matching alert fires.

DPSMF’s anomaly engine builds a rolling baseline for every tracked metric using a 7-day sliding window. It computes the mean and standard deviation for each metric at each time-of-day and day-of-week slot, then scores incoming values against the expected distribution.

When an anomaly fires, DPSMF searches the previous 30 minutes for other anomalies on the same instance. Correlated events are ranked by temporal proximity and knowledge graph relationship strength, then presented in the alert detail view as likely contributing causes.

The knowledge graph is DPSMF’s long-term memory. Every query hash, wait type, metric event, and alert is stored as a node. Observed relationships between them — temporal co-occurrence, causal linkage, query-to-wait attribution — are stored as edges. A taxonomy layer classifies nodes into categories (workload, resource, maintenance, replication, etc.).

Open Knowledge Graph → Explorer (/kg-explorer.html) to browse nodes and edges interactively. Search by query hash, wait type name, metric name, or alert ID. Click any node to see its connected edges and the evidence strength for each relationship.

DPSMF fits a linear trend model to each capacity metric (CPU, buffer pool, data file size, log file size, connection count) using the last 30 days of collected data. It extrapolates forward and identifies the projected date when each metric will breach its defined capacity threshold.

1. 1
   Go to Settings → Instances → Add Instance

   Enter a friendly name, hostname or IP address, and port. The default SQL Server port is 1433.
2. 2
   Enter Credentials

   Choose SQL Auth (username + password) or Windows Auth. Credentials are stored encrypted using AES-256-GCM. They are never displayed in plaintext after saving.
3. 3
   Test & Save

   Click Test Connection to verify. A successful test confirms connectivity and permission adequacy. Click Save — collection begins immediately.

1. 1
   Go to Settings → Users → Add User

   Enter a username, email address, and temporary password (minimum 8 characters).
2. 2
   Assign a Role

   Choose dba, viewer, or readonly. Role controls what actions the user can perform across all DPSMF screens.
3. 3
   Send Credentials

   Share the temporary password with the user. They can change it after first login via Profile → Change Password.

Go to Settings → Users, find the user, and click Reset Password. Enter a new temporary password (min 8 characters). The user will be required to change it on next login.

Go to Settings → License → Activate and enter your license key. Keys take the format DPSMF-XXXXXX-XXXXXX. After activation, the license manager shows the tier, expiry date, instance count, and days remaining.