agentsclimarketplace

Estuary task stats

Skill estuary/agent-skills/skills/estuary-task-stats

Check task processing statistics to see how much data and how many docs are moving. Use when checking throughput, diagnosing a stalled task, verifying data movement, or reporting on task activity. Use when user says "is data flowing", "how much data", "check throughput", "how many documents", "task not processing", "data not arriving", "stats", "bytes processed", "stalled capture", "no data in destination", "data volume", "task report", "usage report", or "how much data did we process".From its SKILL.md

Install
npx -y skills add estuary/agent-skills --skill estuary-task-stats

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 7 commands, including `flowctl raw stats --task <task> --since 24h | jq -s '{ total_gb: ([.[] | select(.materialize != null) | .materialize | to_entries[] | .value.right.bytesTotal // 0] | add // 0 | . / 1073741824 * 10 | r` and 6 more.

SKILL.md

5.3 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

flowctl raw stats - Task Processing Statistics

Concepts: Stats show document and byte counts per transaction for a task. They answer "is data actually moving, and how much?" — separate from flowctl catalog status, which only shows control-plane state. A task can show OK status while having zero recent stats (stalled, no new source data, or sync schedule delay).

IMPORTANT: The command is flowctl raw stats, not flowctl stats.

Prerequisites

flowctl must already be authenticated — see the estuary-flowctl-setup skill.

Total Data Over a Period

Materialization — bytes read from source collections ("Data Read" in UI):

flowctl raw stats --task <task> --since 24h | \
  jq -s '{
    total_gb:     ([.[] | select(.materialize != null) | .materialize | to_entries[] | .value.right.bytesTotal // 0] | add // 0 | . / 1073741824 * 10 | round / 10),
    total_docs:   ([.[] | select(.materialize != null) | .materialize | to_entries[] | .value.right.docsTotal  // 0] | add),
    transactions: ([.[] | select(.materialize != null)] | length)
  }'

Capture — bytes written to Estuary collections ("Data Written" in UI):

flowctl raw stats --task <task> --since 24h | \
  jq -s '{
    total_gb:     ([.[] | select(.capture != null) | .capture | to_entries[] | .value.out.bytesTotal // 0] | add // 0 | . / 1073741824 * 10 | round / 10),
    total_docs:   ([.[] | select(.capture != null) | .capture | to_entries[] | .value.out.docsTotal  // 0] | add),
    transactions: ([.[] | select(.capture != null)] | length)
  }'

Hourly Breakdown

Useful for spotting gaps, spikes, or batch patterns. Matches the hourly bar chart in the Estuary UI.

Materialization:

flowctl raw stats --task <task> --since 48h | \
  jq -s '[.[] | select(.materialize != null) | {
    hour:  .ts[0:13],
    bytes: ([.materialize | to_entries[] | .value.right.bytesTotal // 0] | add),
    docs:  ([.materialize | to_entries[] | .value.right.docsTotal  // 0] | add)
  }] | group_by(.hour) | map({
    hour: .[0].hour,
    gb:   (([.[].bytes] | add) / 1073741824 * 10 | round / 10),
    docs: ([.[].docs]  | add)
  })'

Capture:

flowctl raw stats --task <task> --since 48h | \
  jq -s '[.[] | select(.capture != null) | {
    hour:  .ts[0:13],
    bytes: ([.capture | to_entries[] | .value.out.bytesTotal // 0] | add),
    docs:  ([.capture | to_entries[] | .value.out.docsTotal  // 0] | add)
  }] | group_by(.hour) | map({
    hour: .[0].hour,
    gb:   (([.[].bytes] | add) / 1073741824 * 10 | round / 10),
    docs: ([.[].docs]  | add)
  })'

Hours with no entry = no transactions that hour (expected for gaps, quiet sources, or batch sync schedules).

Stats Structure

Raw entries are nested by task type, then by collection/binding:

{
  "ts": "2026-04-10T00:01:00Z",
  "capture":     { "<collection>": { "out":   { "docsTotal": N, "bytesTotal": N } } },
  "materialize": { "<collection>": { "right": { "docsTotal": N, "bytesTotal": N },
                                     "left":  { "docsTotal": N, "bytesTotal": N },
                                     "out":   { "docsTotal": N, "bytesTotal": N } } },
  "derivation":  { "<transform>":  { "input": { "docsTotal": N }, "out": { "docsTotal": N } } }
}

For materializations:

  • right — docs/bytes read from source Estuary collections ("Data Read" in UI)
  • left — docs/bytes read from the destination (for merging)
  • out — docs/bytes written to the destination

The raw output also contains interval heartbeat entries and ack entries — the select(.materialize != null) / select(.capture != null) filters exclude these.

Diagnosing a Stalled Task

If flowctl catalog status shows OK but data isn't arriving:

# Check for any recent activity
flowctl raw stats --task <task> --since 6h | jq -s '[.[] | select(.materialize != null)] | length'
# → 0 = no transactions in 6h despite OK status

# Run hourly breakdown to find where the gap starts (substitute .capture for capture tasks)
flowctl raw stats --task <task> --since 48h | \
  jq -s '[.[] | select(.materialize != null) | {hour: .ts[0:13], gb: ([.materialize | to_entries[] | .value.right.bytesTotal // 0] | add // 0 | . / 1073741824 * 10 | round / 10)}] | group_by(.hour) | map({hour: .[0].hour, gb: ([.[].gb] | add)})'

Common causes of stats silence with OK status:

  • Source has no new data (expected for quiet sources)
  • Sync schedule delay — materializations batch on a schedule (default: 30 min)
  • Connector in retry backoff — check with flowctl logs --task <task> --since 2h

Related Skills

  • estuary-task-health — Single-task health check combining status, stats, logs, and history
  • estuary-catalog-status — Check control-plane state (running/failed/disabled)
  • estuary-logs — Investigate errors if stats show zero activity

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in ~1.4k tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • use flowctl raw stats for task statistics
  • authenticate flowctl before running commands
  • filter raw output using jq
  • check hourly breakdown to identify gaps
  • compare stats against catalog status

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.