Model Black Friday from last year's data

Why this matters

Every year, capacity planning for Black Friday is a back-of-envelope guess. Someone says “let’s 3x the prod size for the week.” Someone else says “but last year we barely used half of what we provisioned.” Nobody actually pulls the numbers because:

• The data lives in 4 different tools (analytics, CDN logs, app logs, database metrics)
• Nobody has a reliable view of peak per-second — only daily totals
• The pull would take a half-day of someone’s time

Agentry has all your event data in one place — analytics events, error events, deploy events. The peak-second/peak-hour/peak-day query is one HogQL pass. The output is the real numbers you can pin to a Confluence page and have a real infra conversation against.

What you get

• Peak-second ingest rate (the number that matters for rate limits / DB connection pools)
• Peak-hour ingest rate (the number that matters for steady-state capacity)
• Peak-day total (the number that matters for cost forecasting)
• Same metrics for page views, orders, and errors — all from one query

Walk through it

agentry_analytics_query {
  project_id: "default",
  query: "
    with sec_buckets as (
      select toStartOfSecond(timestamp) as sec, count() as evts
      from events
      where timestamp between '2025-11-24' and '2025-11-29'
      group by sec
    ),
    hour_buckets as (
      select toStartOfHour(timestamp) as hr, count() as evts
      from events
      where timestamp between '2025-11-24' and '2025-11-29'
      group by hr
    )
    select
      (select max(evts) from sec_buckets) as peak_per_second,
      (select max(evts) from hour_buckets) as peak_per_hour,
      (select sum(evts) from hour_buckets) as total_window
  "
}

{
  "rows": [
    { "peak_per_second": 1840, "peak_per_hour": 1240000, "total_window": 41200000 }
  ]
}

agentry_analytics_query {
  project_id: "default",
  query: "
    select
      event,
      max(per_hour) as peak_hourly,
      sum(per_hour) as total
    from (
      select event, toStartOfHour(timestamp) as hr, count() as per_hour
      from events
      where timestamp between '2025-11-24' and '2025-11-29'
      group by event, hr
    )
    group by event
    order by peak_hourly desc
    limit 8
  "
}

{
  "rows": [
    { "event": "page_view",         "peak_hourly":  920000, "total": 31800000 },
    { "event": "product_viewed",    "peak_hourly":  190000, "total":  6100000 },
    { "event": "add_to_cart",       "peak_hourly":   42000, "total":  1380000 },
    { "event": "checkout_started",  "peak_hourly":   18400, "total":   612000 },
    { "event": "order_completed",   "peak_hourly":    9100, "total":   312000 },
    { "event": "$exception",        "peak_hourly":    4200, "total":    87000 }
  ]
}

agentry_publish_query {
  recipe_id: "raw_hogql",
  description: "Black Friday 2025 peak load baseline",
  params: { query: "<event-type query from above>" }
}

{ "publication_id": "pub_bf_2025", "public_url": "https://agentry.sh/q/pub_bf_2025?key=agp_…" }

The output

Black Friday 2025 load baseline (Nov 24-28)

Aggregate
  Peak per second:    1,840 events  (23× baseline of ~80)
  Peak per hour:      1.24M  events  (09:00 EST Fri)
  Total in window:    41.2M  events

Per event type (peak hour)
  page_view              920,000  ████████████  (12 instances of normal day-peak)
  product_viewed         190,000  ███           (web app)
  add_to_cart             42,000  ▌
  checkout_started        18,400  ▎
  order_completed          9,100  ▏             ($1.4M GMV that hour at $150 AOV)
  $exception               4,200  ▏             ★ 2x normal error rate

2026 sizing recommendations (1.25× YoY + 2× headroom)
  API peak/sec:        4,600    (provision rate limit)
  Worker peak/hour:    3.1M     (provision concurrency)
  DB QPS peak:        ~9,200    (assuming 2 reads + 1 write per page view)

Public dashboard:
  https://agentry.sh/q/pub_bf_2025?key=agp_xxx

Suggested next investigations:
  - rate-limit-spikes (did any 429s happen during peak hour?)
  - db-pool-exhaustion (did the pool max out?)

Setting it up

This recipe needs no new instrumentation — it’s a pure query against the data you’re already sending. The only prereq is having last year’s analytics in Agentry. If you migrated mid-year, you’ll have to either splice in pre-migration data from your old tool or use a shorter window.

If you want this query to refresh during this year’s peak, register it as a published dashboard and check it live:

// In your war-room dashboard
const res = await fetch(`https://agentry.sh/q/pub_bf_2025?key=${AGP_KEY}&format=json`, {
  headers: { "User-Agent": "warroom/1.0" },
});
const data = await res.json();
renderPeakChart(data.rows);

For a more sophisticated read, pair this with a agentry_register_webhook listening for $exception events — pipe to PagerDuty during the peak window only.

Variations

• “Same query but for Cyber Monday (Dec 1-2). I want to compare BFCM patterns.”
• “By day of the week — does the peak always happen on Friday or did Saturday/Sunday catch up?”
• “Peak rates per region — did EU and APAC peaks line up with US peaks or stagger?”
• “Project this forward to 2026 holiday week assuming 2x growth. What rate limit and DB pool should I size for?”