Usage and billing

Inspect your usage

curl --fail-with-body "$DAGY_API_URL/usage/dashboard?days=30" \
  -H "Authorization: Bearer $DAGY_TOKEN"

The response combines summary, quota, daily, and top_flows. A summary includes period, run_count, task_count, compute_seconds, api_call_count, error_count, and estimated_cost_usd.

Dates use YYYY-MM-DD. Complete fields are in the OpenAPI reference.

Counters and estimates can lag because usage collection is buffered. Missing observations are not proof of zero actual work. Estimates are not invoices or exact upstream cloud bills. Use run-level logs and timings to explain individual failures; use aggregates for trends.

Understand quotas

A quota response includes runs_used, runs_limit, runs_remaining, compute_used, compute_limit, api_calls_used, api_calls_limit, flows_used, flows_limit, warning, over_limit, and human-readable details.

Warnings begin at 80% of metered run, compute, or API-call limits. At the configured limit, normal run submission can return 429 with quota details. The current run admission check also considers the flow count and can reject submission when that count equals the configured maximum. It does not universally block every read or configuration update.

Use GET /billing/plans for the plan catalog applicable to the API you are using and /billing/subscription for the selected account. A zero catalog limit represents an uncapped value in that plan counter, not an absence of rate, runtime, upload, or destination limits. Do not infer unlimited runtime from a plan name.

The standalone quota/dashboard view can report flows_used: 0 even when flows exist. Use the flow list as well when investigating a flow-count-related admission failure. The detailed error from the operation being rejected is more useful than a stale or incomplete summary.

Distinguish quotas from request rate limits

Monthly quotas and request-rate budgets are separate. A temporary rate limit can recover after a delay. A monthly quota usually needs reduced consumption, a new quota period, or an account change. Read the error body before retrying.

The default normal request budget is 120 requests per minute with a burst allowance of 200. AI/streaming routes use a separate smaller budget (20 per minute, burst 30), and device grant creation/approval use 20 per minute, burst 20. Inbound webhook sensors also have a per-token budget. Availability and configured limits can differ across deployments.

Rate budgets are separated by credential/identity and endpoint class. They are not a promise of one shared workspace-wide request counter. Successful responses can include X-RateLimit-Limit and X-RateLimit-Remaining; honor Retry-After when an error provides it and use bounded backoff otherwise. See Errors and retries.

Billing availability

Subscription status and plan/usage reporting are implemented. Customer self-service checkout and billing-portal session creation are not implemented as real payment workflows in the current product. Do not build purchasing or subscription changes around placeholder checkout/portal URLs. Ask your workspace owner or dagy.io account support for the available plan-change process.

Provider billing callbacks are platform-managed endpoints; they are not customer event subscriptions. For events your application can send or receive, use event sensors and notification channels.

Reduce avoidable consumption

Use bounded polling, date/flow filters, and batch work when your data source supports it. Preview backfills before creating thousands of runs. Reuse successful task outputs only where the runtime supports it, and keep tasks idempotent so recovery does not duplicate destination data.

If a usage value appears inconsistent, retain the workspace ID, relevant run IDs, UTC time range, endpoint response, and quota error. Share a redacted report through the workspace support channel rather than exposing credentials or customer payloads.