> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Throughput (req/s), Datadog > Throughput (req/s) for Datadog stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Monitoring](/nerve-centre/connectors#connectors-by-type) ## At a glance > The number of requests per second your storefront services are handling. For a merchant, this is "how busy is my site right now?" A sudden drop typically signals one of three things: traffic is gone (acquisition channel down), the site is broken (and shoppers cannot make requests), or measurement is broken (and the requests are happening but not being counted). | | | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **API endpoint** | Datadog Metrics API, `GET /api/v1/query` with `sum:trace.servlet.request.hits{*}.as_rate()` (or the runtime equivalent). | | **Metric basis** | APM span-count rate. Each request that enters an instrumented service counts as one hit. | | **Aggregation window** | 1-minute rollup; the card displays the rolling 5-minute average against the same hour-of-week from the prior 7 days. | | **Severity threshold** | P1 = drop above 50% WoW (likely outage or measurement break); P2 = drop above 30% WoW (alert trigger); P3 = drop above 15% WoW (worth investigating). | | **Alert pre-filtering** | Synthetic test traffic and health-check endpoints are excluded by default to prevent test cadence from masking real traffic dips. | | **Log Management gating** | Not used. Throughput is APM-derived; the card returns valid values regardless of Logs status. | | **Filtered hosts / services** | All instrumented services. For per-service breakdown see [Throughput by Service](/nerve-centre/kpi-cards/datadog/throughput-by-service). | | **Time zone** | Account timezone for "same hour of week" comparison; UTC for cross-connector windowing. The day-of-week comparison is critical: comparing 03:00 Sunday against 03:00 Wednesday produces meaningless deltas. | | **Why "same hour of week" rather than yesterday** | Ecommerce traffic is highly cyclical: Tuesday afternoon does not look like Saturday afternoon, and Saturday afternoon does not look like Sunday morning. The same-hour-of-week comparison is the noise-reducing baseline that lets a 30% drop alert mean what it sounds like it means. | | **Time window** | `T/7D vsP` (today vs the same hour of week, 7 days prior) | | **Alert trigger** | `drop >30% WoW`, sustained for 5 minutes pages on-call. | | **Sentiment key** | `throughput` | | **Roles** | owner, engineering, operations | ## Calculation Calculated automatically from your Datadog data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A US specialty foods brand on BigCommerce running paid Google Search and Meta ads as the primary acquisition channel. Throughput baselined at 145 req/s on weekday afternoons. On 18 Apr 26 the baseline collapsed to 88 req/s without warning. | Time (UTC) | Throughput (req/s) | WoW delta | What was happening | | ------------------------ | ------------------ | --------- | ----------------------------- | | 14:00 (typical Tuesday) | 145 | baseline | Normal traffic | | 14:00 (incident Tuesday) | 88 | **-39%** | Alert fired | | 14:15 | 91 | -37% | Investigation begins | | 14:30 | 86 | -41% | Confirmed not a Datadog issue | | 14:45 | 87 | -40% | Cause identified | | 15:30 | 144 | -1% | Recovered | **Three things were checked in order, all wrong before they hit the right one:** 1. **Site outage?** No, the synthetic checkout test was passing, [Critical-Path Tests Status](/nerve-centre/kpi-cards/datadog/critical-path-tests-status) was green, and APM error rate was at baseline (0.4%). The site was up and shoppers who reached it were having a normal experience. 2. **Datadog measurement break?** No, [Reporting Hosts](/nerve-centre/kpi-cards/datadog/reporting-hosts) was steady, no agents were marked stale, and APM span ingestion was on schedule. The numbers were real. 3. **Acquisition channel down.** Google Ads had paused the merchant's main ad group at 13:55 because their billing card had expired. No payment, no ads, no traffic. The drop in throughput was a 100% accurate reflection of the drop in paid-traffic clicks. The fix was a 5-minute card update in Google Ads. ```text theme={null} Revenue impact: - 1.5 hours below baseline at -40% throughput - Baseline conversion rate: 1.7% - Baseline AOV: $52 - Lost sessions ≈ (145 − 88) × 60 × 90 ≈ 308,000 sessions - Wait, that is sessions not orders. Orders ≈ 308,000 × 0.017 = 5,236 - That seems high; the right framing: lost ORDERS ≈ baseline_orders/min × 1.5h × 0.40 - At baseline 5 orders/min × 90 min × 0.40 = 180 lost orders - At AOV $52: lost revenue ≈ $9,360 ``` Three takeaways merchants should remember: 1. **A throughput drop is not always a site problem.** Roughly half the time it is an acquisition-channel problem: paused ad spend, expired payment method on Google Ads / Meta, an organic-search ranking drop, an email send-list issue. The site is fine; the inbound funnel is throttled. **Pair throughput with the relevant acquisition card before assuming a technical incident.** 2. **The "same hour of week" baseline is critical.** This brand's Sunday afternoon throughput is only 60 req/s, well below the 145 req/s Tuesday baseline. Comparing Sunday to Tuesday would falsely flag a 60% drop as catastrophic when it is just normal weekly cycling. WoW comparison removes this noise. 3. **Drops below the 30% threshold without obvious cause are usually one of three: ad-spend pause, CDN configuration change (some traffic is now bypassing your APM-instrumented services), or a measurement-side regression.** Investigate in that order; the first two cover 80% of cases. ## Sibling cards merchants should reference together | Card | Why pair it with Throughput | What the combination tells you | | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | [Throughput by Service](/nerve-centre/kpi-cards/datadog/throughput-by-service) | The per-service breakdown. When the headline drops, this card identifies which service is starved. | All services dropping together equals upstream/CDN issue; one service dropping equals routing or instrumentation issue. | | [Error Rate](/nerve-centre/kpi-cards/datadog/error-rate) | The classic pairing: throughput down + errors up equals capacity-limited; throughput down + errors flat equals demand-limited (acquisition issue). | Direction of the relationship reveals the cause. | | [p95 Response Time](/nerve-centre/kpi-cards/datadog/p95-response-time) | Throughput and latency trade off in capacity events; in demand events latency stays flat. | Throughput down + latency up equals overload; throughput down + latency steady equals demand drop. | | [Active Incidents](/nerve-centre/kpi-cards/datadog/active-incidents) | When throughput drops without an incident already open, you may need to declare one. | An open incident contextualises the drop; absence of an incident means investigate first. | | [Critical-Path Tests Status](/nerve-centre/kpi-cards/datadog/critical-path-tests-status) | Synthetic tests run at constant cadence; if real throughput drops but synthetics are green, the site is up but the funnel is starved. | Synthetic green plus real-traffic drop equals demand-side problem (acquisition, marketing, organic). | | [Google Ads Spend / Click](/nerve-centre/google_ads/ads_spend) | The most common cause of throughput drops at small-mid merchants. | Sudden ad-spend pause reflects in throughput within 15-30 minutes. | | [GA4 Sessions](/nerve-centre/kpi-cards/google-analytics/sessions) | The browser-side peer. GA4 sessions and Datadog throughput should move together. | If GA4 sessions are steady but Datadog throughput dropped, the gap is on the server-routing side. | | [Shopify / BC / Adobe Total Revenue](/nerve-centre/kpi-cards/shopify/total-revenue) | The downstream impact metric. | Throughput drop without revenue drop equals bot/cache traffic was the lost portion (less concerning); with revenue drop equals genuine shopper loss. | ## Reconciling against the vendor's own dashboard **Where to look in Datadog:** > **[APM → Service List](https://app.datadoghq.com/apm/services)** for per-service hits-per-second. > **[Dashboards → APM Overview](https://app.datadoghq.com/dashboard/lists)** for the time-series view. > **[APM → Service Map](https://app.datadoghq.com/apm/map)** to see how request volume flows across services. **Why our number may legitimately differ from Datadog's UI:** | Reason | Direction | Why | | ------------------------ | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Time zone** | Boundary days off | Datadog UI uses account timezone; Vortex IQ uses UTC for cross-connector windowing. The "same hour of week" comparison aligns to UTC by default. | | **API rate limits** | Brief gaps | The Metrics query API is rate-limited; on burst minutes a polled value may use cached prior data. | | **Log indexing latency** | Not applicable | Throughput is APM-derived. | | **Span sampling** | Either direction | Head-based sampling at \<100% reduces the absolute count proportionally. The displayed number is multiplied back up using your configured sample rate; if the sample rate setting is wrong, the numbers diverge. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes the divergence | | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`google_analytics.ga_sessions`](/nerve-centre/kpi-cards/google-analytics/sessions) | GA4 sessions per minute should track Datadog throughput within a 1.5x-2x ratio (multiple requests per session). | A widening gap (GA4 stable, Datadog dropping) means traffic is hitting the CDN cache and bypassing instrumented services; the inverse means GA4 tag-fire is broken. | | [`shopify.total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) / [`bigcommerce.total_revenue`](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | Revenue/min lags throughput by 5-15 minutes during normal cycles. | Throughput drop without revenue drop typically means bot/crawler traffic was the lost portion. | | Datadog logs | Subset relationship: log volume scales roughly with throughput at constant verbosity. | If throughput is stable but log volume jumps, you have a runaway-logging regression (often debug logs accidentally left enabled). |
Documentation cross-reference (same-metric peer) Throughput exists with the same definition on every observability platform. This is **not** a reconciliation, your Datadog account does not have a parallel New Relic instance to compare against. These references exist purely so an agency running clients on multiple monitoring stacks can cross-link the same metric across docs. * New Relic equivalent: NerdGraph `count(*) FROM Span` returns the same shape per second.
## Known limitations / merchant FAQs **My throughput dropped but the site looks fine. What is happening?** The most common causes, in order: (1) Paid ads paused (billing card expired, daily budget hit, ad account flagged); (2) Organic-search ranking dropped; (3) An email send did not go out on schedule; (4) A CDN configuration change is now caching pages that previously hit your origin; (5) A measurement-side regression (Datadog agent down, instrumentation removed in a deploy). Check acquisition channels first; technical investigation is item 5 of 5, not item 1. **Why does the alert use "Week-over-Week" rather than "vs yesterday"?** Ecommerce traffic is highly cyclical by day-of-week. Tuesday afternoon is not Saturday afternoon. The same-hour-of-week comparison removes that periodicity so a real 30% drop alert means "this is unusual versus the same time last week" rather than "this is unusual versus the typical Sunday morning". WoW is the right baseline for retail. **My throughput is up 50% but my revenue is flat. Should I be worried?** Not necessarily, but investigate. Three benign causes: (1) Bot traffic spike (crawler indexing your sitemap aggressively); (2) A successful but mistargeted ad campaign drove low-intent traffic; (3) Cache miss rate dropped on the CDN, increasing origin throughput without changing real shopper count. One concerning cause: a paid scraper or competitive-intel bot is hammering your product pages. Check [Top Slow Endpoints](/nerve-centre/kpi-cards/datadog/top-slow-endpoints) and look for endpoints with abnormally high request counts but low conversion contribution. **Datadog says throughput is fine but Google Analytics shows sessions dropping.** GA4 measures *browser-side* sessions; Datadog measures *server-side* requests. A widening gap (Datadog stable, GA4 dropping) almost always means a tag-fire or consent-banner regression on the browser side, not a real traffic loss. Open [GA4 Property Health](/nerve-centre/kpi-cards/google-analytics/ga4-property-health). If Property Health is amber, the GA4 numbers are unreliable and Datadog throughput is the source of truth. **My Logs API returns 400 No valid indexes. Does this card still work?** Yes. Throughput is APM-derived. Log Management gating only affects log-volume cards. The Vortex IQ engine logs the gating event once at INFO level and continues serving APM-derived cards normally. **What is the difference between Datadog throughput and a load balancer's request count?** Load balancer counts every request that hits the LB; Datadog APM counts every request that reaches an instrumented service. Differences: (1) LB sees CDN-bypass requests Datadog does not (cached responses), (2) LB sees blocked-at-WAF requests Datadog does not (Cloudflare WAF or AWS WAF blocks before APM), (3) Datadog sees worker/job spans the LB does not. For "is shopper traffic arriving", LB is the truth; for "is shopper traffic being processed by my application", Datadog is. **My throughput chart shows a flat line at zero from 02:00 to 06:00. Is the site down?** Almost certainly not. Most ecommerce sites genuinely have near-zero traffic in the small hours of the local timezone, especially regional brands. Datadog is doing its job; the lack of traffic is real. The "low-confidence" flag on the card prevents alert spam during these windows. If your brand has international traffic and you genuinely expect non-zero overnight throughput, raise this in \[Settings → Alerts → Per-card thresholds]. **Throughput spiked 5x for 30 seconds and then went back to normal. What was that?** Three usual causes: (1) A bot wave hit a rate-limit and bounced (you will see a 503 spike in [5xx Response Rate](/nerve-centre/kpi-cards/datadog/5xx-response-rate) at the same moment), (2) A cache invalidation triggered a thundering-herd on the origin, (3) A scheduled cron or deploy hook fired and made many internal requests. None of these is a customer-facing event. **My multi-region store has different throughput per region. How is it shown?** The headline is the global sum across all regions. For per-region breakdown, use [Uptime by Region](/nerve-centre/kpi-cards/datadog/uptime-by-region) (synthetic-test view) or filter the Datadog query by `@datacenter:` tag. Vortex IQ's per-region throughput stacked panel is on the roadmap. *** ### Tracked live in Vortex IQ Nerve Centre *Throughput (req/s)* is one of hundreds of KPI pulses Vortex IQ tracks across Datadog and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.