Metrics

What Metrics Measure

FastHook keeps request metrics and event metrics separate because they answer different operational questions. Requests describe what producers sent into FastHook. Events describe what FastHook created for destination delivery after routing, filters, deduplication, pause state, retries, and replay decisions.

Both metrics endpoints return the same top-level JSON envelope: date_range, granularity, and series. The fields inside each series bucket are endpoint-specific and only include the measures you request.

• Request metrics answer whether a provider is still sending traffic and whether FastHook is accepting or rejecting it.
• Event metrics answer whether destination branches are delivering, failing, queued, processing, held, or ignored.
• A single inbound request can create zero, one, or many outbound events depending on routing and fan-out.
• Rejected requests do not create delivery events.
• Ignored events can be created by filters, deduplication, or route decisions before delivery.

Request Metrics

Use request metrics first when a provider, customer, or internal team says traffic is missing. They show whether FastHook received the inbound calls over the selected time range.

• Count inbound requests accepted by sources.
• Compare accepted_count and rejected_count to separate ingress problems from delivery problems.
• Filter by source_id when a specific provider environment looks suspicious.
• Filter by status accepted or rejected when signature verification, source configuration, or request validation may be blocking traffic.
• Use q for operator search workflows when you need to inspect a subset of recorded traffic.

fasthook metrics requests --source_id src_xxx --from 2026-05-25T00:00:00Z --to 2026-05-25T23:59:59Z

curl "https://api.fasthook.io/v1/metrics/requests?date_range[start]=2026-05-25T00:00:00Z&date_range[end]=2026-05-25T23:59:59Z&granularity=1m&source_id=src_xxx&measures[]=count&measures[]=accepted_count&measures[]=rejected_count" \
  -H "Authorization: Bearer fhp_xxx"

Event Metrics

Use event metrics when FastHook is receiving traffic but one or more downstream branches are unhealthy. Event status shows where delivery work is accumulating or failing.

• Track delivered_count, failed_count, queued_count, processing_count, hold_count, and ignored_count.
• Filter by destination_id when one receiver is slow, overloaded, or returning errors.
• Filter by connection_id when a fan-out route has several branches pointing at different destinations.
• Filter by source_id when one producer is creating pressure across many destinations.
• Filter by batch_operation_id to watch traffic created by replay or bulk retry.

fasthook metrics events --destination_id des_xxx --from 2026-05-25T00:00:00Z --to 2026-05-25T23:59:59Z

curl "https://api.fasthook.io/v1/metrics/events?date_range[start]=2026-05-25T00:00:00Z&date_range[end]=2026-05-25T23:59:59Z&granularity=1m&destination_id=des_xxx&measures[]=delivered_count&measures[]=failed_count&measures[]=hold_count" \
  -H "Authorization: Bearer fhp_xxx"

Granularity And Time Ranges

Metrics endpoints return zero-filled time series for the requested range. Pick a bucket size that matches the question. Small buckets are useful while debugging a short incident. Larger buckets are better for dashboards and daily reporting.

• Use 1s, 5s, 10s, or 30s for short bursts, provider tests, and active incident debugging.
• Use 1m, 5m, or 15m for deploy windows, retry recovery, and normal operational dashboards.
• Use 1h for longer reports where the trend matters more than each individual spike.
• Compare request and event series over the same range before deciding where the problem lives.
• Include the deploy, provider incident, or replay window in the selected time range.

Status Signals

Status counts are the fastest way to understand whether FastHook is ingesting, routing, delivering, or holding work. Treat them as a map for the next inspection step.

• accepted_count rising means FastHook is receiving and accepting inbound provider traffic.
• rejected_count rising means the source is rejecting traffic before destination delivery begins.
• delivered_count rising means destination branches are succeeding.
• failed_count rising means receivers, destination configuration, or the network path need inspection.
• queued_count or processing_count staying high means delivery workers or receiver latency may be under pressure.
• hold_count rising means events are paused, scheduled, rate-limited, or waiting for a later delivery path.
• ignored_count rising means filters, deduplication, or routing decisions are preventing delivery.

Incident Workflow

During an incident, metrics help you move from broad symptoms to a narrow set of requests, events, and attempts. Use metrics to identify the shape, then inspect records to find the exact payloads and receiver responses.

• If request volume drops to zero, check the provider configuration, source URL, and provider incident status.
• If rejected_count rises, inspect source validation, signatures, and request records.
• If request volume is normal but failed_count rises, inspect destination attempts and receiver logs.
• If hold_count rises, check paused connections, delayed delivery, retry scheduling, and destination throughput limits.
• If ignored_count rises, check filters and deduplication rules before assuming delivery failed.

# 1. Confirm whether the provider is still sending traffic.
fasthook metrics requests --source_id src_xxx --from 2026-05-25T10:00:00Z --to 2026-05-25T10:30:00Z

# 2. Check whether a destination branch is failing or holding work.
fasthook metrics events --destination_id des_xxx --from 2026-05-25T10:00:00Z --to 2026-05-25T10:30:00Z

# 3. Inspect the exact failed events and attempts.
fasthook events list --destination_id des_xxx --status failed --limit 50
fasthook attempts list --event_id evt_xxx

Dashboards And Alerts

Use the metrics API for dashboards, alerts, and operational reports. The response shape is stable enough to feed time-series charts while the request, event, and attempt APIs remain available for drill-down.

• Alert on rejected request spikes for production sources.
• Alert on failed event spikes for critical destinations.
• Track hold_count for paused routes and constrained receivers.
• Track ignored_count when a new filter or deduplication rule is deployed.
• Group dashboards by source, destination, and connection so fan-out branches do not hide each other.
• Keep API-key based automation scoped to the project that owns the route.

How To Read The Series

Every response includes date_range, granularity, and a series array. Each series item represents one bucket starting at timestamp. Buckets with no matching records are returned with zero counts so charts do not need to guess about missing points.

Request metrics and event metrics share the envelope, but they do not share the same measure fields. Request buckets use count, accepted_count, and rejected_count. Event buckets use count, delivered_count, failed_count, queued_count, processing_count, hold_count, and ignored_count.

// /v1/metrics/requests
{
  "date_range": {
    "start": "2026-05-25T10:00:00.000Z",
    "end": "2026-05-25T10:30:00.000Z"
  },
  "granularity": "1m",
  "series": [
    {
      "timestamp": "2026-05-25T10:00:00.000Z",
      "count": 12,
      "accepted_count": 11,
      "rejected_count": 1
    }
  ]
}

// /v1/metrics/events
{
  "date_range": {
    "start": "2026-05-25T10:00:00.000Z",
    "end": "2026-05-25T10:30:00.000Z"
  },
  "granularity": "1m",
  "series": [
    {
      "timestamp": "2026-05-25T10:00:00.000Z",
      "count": 12,
      "delivered_count": 11,
      "failed_count": 1,
      "queued_count": 0,
      "processing_count": 0,
      "hold_count": 0,
      "ignored_count": 0
    }
  ]
}

Common Questions

• Provider sent traffic but my app saw nothing: compare request accepted_count with event delivered_count for the destination.
• A replay is running too fast: watch event metrics by batch_operation_id and destination_id, then adjust throughput controls.
• Only one fan-out branch is failing: filter event metrics by connection_id or destination_id instead of looking only at source totals.
• Traffic was rejected at ingress: inspect request records and source verification settings before looking at destination attempts.
• A route is paused: hold_count should rise for that connection until it is unpaused and drained.

Next

• Metrics endpoints
• Webhook debugging
• Retries
• Control throughput