Documentation

Damasqas connects to your data stack and lives inside Slack. Ask questions in plain English, get alerted when things go wrong, set up monitoring without config files, and verify PRs in isolated sandboxes — all without leaving your workspace.

Getting Started

After installing Damasqas to your Slack workspace, connect your integrations from the admin dashboard:

• Database — your production Postgres instance
• Workflows — your Temporal cluster
• Infrastructure — your Railway project
• Code — your GitHub organization

Asking Questions About Your Data

You can ask Damasqas anything about your data in plain English. It knows your schema, your pipeline history, your deployments, and your code — and it connects the dots across all of them automatically.

Data & schema questions

Y

You

@damasqas how many orders came in yesterday?

damasqas

Here's what I found:SELECT COUNT(*) FROM orders
WHERE created_at >= '2024-01-14' AND created_at < '2024-01-15'4,821 orders on January 14th.That's up 12% from the 7-day average of 4,302.

Y

You

@damasqas show me the last 5 failed payments and what orders they belong to

damasqas

SELECT p.id, p.amount, p.status, p.created_at, o.customer_id
FROM payments p JOIN orders o ON o.id = p.order_id
WHERE p.status = 'failed' ORDER BY p.created_at DESC LIMIT 5

payment	amount	time	customer
pay_a1b2	$142.00	Jan 14, 15:32	cust_882
pay_c3d4	$89.50	Jan 14, 14:11	cust_341
pay_e5f6	$310.00	Jan 14, 12:55	cust_119
pay_g7h8	$22.00	Jan 14, 11:44	cust_774
pay_i9j0	$56.75	Jan 14, 09:20	cust_502

All 5 failed with a card_declined error. Want me to check if there's a pattern in the provider logs?

Y

You

yes please

damasqas

I pulled the infrastructure logs for the payment service. All 5 declines hit the Stripe API between 09:00–16:00 today. Stripe's status page shows a partial outage on their card auth service from 08:45–16:20 UTC.

This is a Stripe-side issue, not your code. The failed payments can likely be retried now — want me to check how many total failed in that window?

Tracing a record through your pipeline

Trace a single record end-to-end across every table it touches.

Y

You

@damasqas trace order #8821 through the pipeline

damasqas

Full journey for order #8821:

orders id=8821
→ placed Jan 14 at 10:02 · customer cust_441 · $278.00 · status: completed

payments order_id=8821
→ pay_x7y8 · $278.00 · Stripe · status: completed at 10:02

fulfillment_jobs order_id=8821
→ job_4421 · queued 10:02 · started 10:04 · completed 10:09

shipments order_id=8821
→ ship_9932 · UPS · delivered Jan 15

invoices order_id=8821
→ inv_2241 · sent Jan 14 at 10:10 · opened Jan 14 at 11:33

Everything looks healthy. Let me know if you want to dig into any step.

Debugging pipeline failures

Y

You

@damasqas the revenue-sync workflow failed this morning, what happened?

damasqas

Workflow: revenue-sync · Run run_a8b9c0
Failed at: 03:14 AM · Activity: transform_payments (attempt 3/3)
Error: column "amount" does not exist
LINE 1: SELECT id, order_id, amount, currency FROM payments... Deploy #91 went live at 03:02 AM. PR #147 renamed payments.amount → payments.total_amount. The migration ran, but the workflow still references the old name on line 42 of sync/revenue.ts.

Root cause: schema change not reflected in ETL code
- amount,
+ total_amount AS amount, Want me to check if any other workflows reference payments.amount?

Y

You

yes

damasqas

Found 2 more affected workflows:

1. nightly-reconciliation — reconcile/payments.ts line 88
2. monthly-invoicing — invoicing/aggregate.ts line 31

Both are scheduled tonight. Patch all three before then.

Pipeline Failure Alerts

Damasqas watches your workflows continuously. The moment a pipeline fails, you get an alert in Slack with an AI-generated root cause analysis.

damasqas#data-alerts

🔴 Pipeline Failure: revenue-sync

Run run_a8b9c0 · Started 03:02 AM · Failed 03:14 AM · 12m

Root cause: schema_change — payments.amount was renamed in deploy #91. The ETL still references the old name.

Suggested fix: Update sync/revenue.ts line 42.

View in TemporalAcknowledge

Every alert includes: which workflow failed and when, the exact error, AI-classified root cause, a suggested fix based on your code and recent deploys, and a link to the full execution history.

SLA Monitoring

Set deadline-based SLAs on critical workflows. Damasqas warns you before a deadline is missed.

damasqas#data-alerts

⚠️ SLA Warning: revenue-sync

Due by 09:00 AM ET (30 min from now) and hasn't completed. Running for 2h 18m — the last 3 runs took 38m, 41m, 44m. This is 3× longer than normal.

damasqas#data-alerts

🔴 SLA Breached: revenue-sync

The 09:00 AM ET deadline has passed. Still running at 2h 52m.

damasqas#data-alerts

✅ SLA Resolved: revenue-sync

Completed at 09:08 AM ET — 8 minutes late. Total: 2h 56m.

Data Quality Monitoring

Damasqas monitors your tables for anomalies automatically. It learns baselines and alerts when something drifts.

damasqas#data-quality

🟡 Anomaly: users.email null rate

Baseline: 0.3% · Current: 14.2% ↑ 47×
14,200 of 100,000 recent users missing an email. Spike started ~2:15 PM when deploy #89 went out.

Acknowledge

Setting Up Monitors in Plain English

Describe what you want to watch in Slack. No YAML. No dashboard. Damasqas figures out the rest.

Y

You

@damasqas alert me if our order count drops below 100 in any hour

damasqas

Got it — two quick questions:
1. Which channel for alerts?
2. How long before re-alerting?

Y

You

#sales-ops, re-alert every 2 hours

damasqas

Monitor created ✅

Watching:SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL '1 hour'Alert when result < 100
Schedule: every hour
Channel: #sales-ops
Cooldown: 2 hours

Y

You

@damasqas warn me if the payments table hasn't been updated in over 30 minutes during business hours

damasqas

What counts as business hours, and which channel?

Y

You

9am to 7pm ET weekdays, #data-alerts

damasqas

Monitor created ✅

Watching: freshness of public.payments
Threshold: no new rows for > 30 min
Active: Mon–Fri, 09:00–19:00 ET
Channel: #data-alerts

Y

You

@damasqas ping me if the nightly ETL takes longer than 2 hours. Post to #data-team and mention @oncall

damasqas

Monitor created ✅

Watching: nightly-etl duration
Threshold: > 2 hours
Channel: #data-team with @oncall

Y

You

@damasqas let me know when any PR gets merged into main on the payments repo

damasqas

Monitor created ✅

Trigger: PR merged → main on payments
Channel: this channel (#dev-feed)

Supported monitors: SQL metrics, workflow duration, deadline SLAs, table freshness, NULL rate, row count changes, custom SQL, workflow failures/completions, deployments, PR merges, schema changes, and row inserts matching criteria.

Rule-Based Automation

Automate responses to pipeline events in plain English. Describe the rule once — Damasqas parses it, stores it, runs it.

Y

You

@damasqas if revenue-sync fails 3 times in a row, alert #sales-ops

damasqas

Rule created ✅

Trigger: revenue-sync fails 3× consecutively
Action: alert #sales-ops

Watching immediately.

Y

You

@damasqas every Monday at 9am post a pipeline health summary to #data-team

damasqas

Rule created ✅

Trigger: Every Monday 09:00 AM
Action: pipeline summary → #data-team

Y

You

@damasqas if null rate on payments.amount goes above 5%, pause the revenue-sync schedule

damasqas

This rule modifies your pipeline — I'll need approval each time it triggers.

Rule created ✅ (requires approval)

Trigger: payments.amount null rate > 5%
Action: pause revenue-sync
Approval: yes — I'll ask before pausing anything

Approval workflow

Actions that modify pipelines (retry, pause) require explicit approval before Damasqas acts.

damasqas#data-team

Rule triggered: Payments Null Rate Circuit Breaker

payments.amount null rate is 7.3% (threshold: 5%).

Proposed: Pause revenue-sync schedule
No new runs until manually resumed.

ApproveDeny

Actions reference

Sandbox & PR Verification

When a PR is opened, Damasqas spins up a fresh isolated environment, runs your tests, and reports results to the GitHub PR and Slack — before anything touches production.

1. PR is opened or updated
2. Damasqas provisions a clean environment
3. Auto-detects your stack (language, framework, database, test runner)
4. Builds, runs migrations, executes tests
5. Results posted to GitHub PR check and Slack

damasqas#eng

✅ Sandbox passed — PR #147

Step	Result	Time
Build	✅	42s
Migrations	✅	3s
Unit tests	✅	18s
Integration tests	✅	1m 12s

Total: 2m 15s

View terminalView on GitHub

damasqas#eng

❌ Sandbox failed — PR #147

Step	Result	Time
Build	✅	38s
Migrations	✅	3s
Unit tests	❌	22s
Integration	⏭ skipped	—

FAIL src/sync/revenue.test.ts
  ✕ transforms payment amount correctly (3ms)

    TypeError: Cannot read property 'amount' of undefined
    at transformPayment (sync/revenue.ts:42:18)

View full logsView on GitHub

Custom sandbox configuration

Add damasqas.sandbox.yml to your repo root:

build:
  command: npm ci && npm run build

setup:
  - npm run db:migrate
  - npm run db:seed:test

verify:
  steps:
    - name: unit tests
      command: npm test
    - name: integration tests
      command: npm run test:integration
      depends_on: [unit tests]
    - name: e2e tests
      command: npm run test:e2e
      depends_on: [integration tests]

Steps run in dependency order. If one fails, dependents are skipped automatically.

The Admin Dashboard

Integrations — Connect and update credentials for your database, workflows, infrastructure, and code. All credentials are encrypted and never visible after saving.

Alert Configurations — Create, edit, and delete pipeline failure alerts, SLA configs, data quality checks, and natural language monitors from one interface.

Sandboxes — History of sandbox runs with status, step results, and logs.

Analytics — Queries run, rows fetched, workflows debugged, estimated time saved.

Team & Access — Manage approvers, workspace settings, and notification preferences.