Skip to main content

STATS

Overview​

Stats provides comprehensive analytics and performance metrics for your store. View historical data with interactive graphs showing records, API requests, and search response times. Use date-range filtering to analyze trends and optimize performance through Configuration settings.

Why Use Stats?​

Stats help you:

  • Analyze trends - Understand usage patterns over time
  • Monitor performance - Track response times and identify bottlenecks
  • Plan capacity - Forecast based on historical data
  • Identify issues - Spot anomalies and performance degradation
  • Optimize resources - Make data-driven decisions

Real-World Example: Notice a spike in search requests but declining response times? Stats graphs help you identify when performance degraded and correlate it with increased load. Use API Logs for detailed investigation and Configuration for optimization.

Date Range Selector​

Quick Access Options​

API Stats

Quick Options:

  • Last 7 days (default)
  • Last 30 days
  • Last 3 months
  • Custom Range

Key Metrics Cards​

Three summary cards display high-level statistics:

Stats Cards
1. Total Records2. Total Requests3. Avg Response Time

Meaning:

Total number of records/documents in your index

Use:

  • Monitor index size (configure in Configuration)
  • Track content growth and plan capacity
  • Verify data import success (compare with Browse results)

Meaning:

Total API requests made during selected period

Use:

  • Understand API usage volume (detailed view in API Logs)
  • Identify traffic patterns and peak usage times
  • Plan rate limits and capacity (configure in Configuration)

Meaning:

Average API response time in milliseconds

Use:

  • Monitor performance health (real-time view in API Logs)
  • Identify performance degradation trends
  • Set performance benchmarks and alerts in Configuration

Records Graph​

Stats Records Graph

Title: Records

Purpose: Visualize index record changes over time

Y-AxisX-AxisLegend

Record count (0 to 10000+ scale)

Dates (Nov 25 - Dec 1)

Purple line: Plan limit
Blue line: Actual records

Understanding the Records Graph​

What to MonitorPurple Line (Included)Blue Line (Used)
  • Gap between lines shows available capacity
  • Blue approaching purple means plan upgrade needed
  • Sharp drops indicate index rebuilds or data deletion
  • Steady growth is normal usage pattern
  • Your plan's record limit
  • Maximum records allowed
  • Current records in your index
  • Actual usage

API Requests Graph​

API Stats Requests Graph
OverviewGraph Elements

Title:

API requests

Purpose:

Breakdown of API request types over time

Display:

Interactive bar chart with color-coded segments showing API request distribution across different categories and time periods for comprehensive analysis

Y-Axis:

Request count (0 to 220+ scale)

X-Axis:

Dates (Nov 25 - Dec 1)

Legend:

Green: Search requests
Blue: Build requests
Red: Errors
Gray: Others

Understanding the API Requests Graph​

What to MonitorColor Segments
  • High green bars = increased user activity (analyze in Browse)
  • Red segments = errors requiring investigation (debug in API Logs)
  • Blue spikes = scheduled builds or data imports (configure in Configuration)
  • Total height shows overall API usage trends
Green (Search): User search activity and queries
Blue (Build): Index updates and data imports
Red (Errors): Failed requests that need attention
Gray (Other): Admin operations

Search Response Time Graph​

Search Response Time Graph
OverviewPerformance Metrics

Title:

Search response time (in ms)

Purpose:

Monitor search performance over time

Display:

Interactive line graph with multiple percentile markers showing real-time performance trends and statistical distribution of response times across different time periods

Average response time:

0.00ms

90th percentile:

0.00ms

Note:

Values at 0ms may indicate:

  • Very low traffic during period
  • Performance logging not yet active
  • Data not yet available for new stores
Graph ElementsLegend

Y-Axis:

Response time in milliseconds (0ms to 4ms scale)

X-Axis:

Dates (Nov 25 - Dec 1)

Blue line (Average): Mean response time
Purple line (90th percentile): 90% of requests faster than this
Yellow line (99th percentile): 99% of requests faster than this

Understanding the Response Time Graph​

Three Performance LinesPerformance BenchmarksWhat to Monitor
Blue (Average):
Mean response time across
all requests
Purple (90th percentile):
90% of requests are faster
than this
Yellow (99th percentile):
99% of requests are faster
than this
  • Excellent:
    Average less than 100ms,
    90th less than 200ms
  • Good:
    Average 100-300ms,
    90th 200-500ms
  • Needs Attention:
    Average greater than 300ms,
    90th greater than 500ms

Default Timezone Note​

Stats Timezone
DisplayMeaningJump to top

Default timezone is UTC

  • All timestamps in UTC (Coordinated
    Universal Time)
  • Adjust mentally for your local timezone
  • Example: EST = UTC - 5 hours

Link to scroll back to page top

Working with Stats​

Week-over-WeekIdentify Patterns
  1. Select "Last 7 days"
  2. Note key metrics
  3. Change to "Last 30 days"
  4. Compare patterns and analyze differences in usage trends, performance metrics, and overall system behavior
  • Regular spikes (scheduled jobs?)
  • Weekly cycles (user behavior?)
  • Declining performance
    (scaling needed?)

Performance Optimization​

Step 1: Check response time graphStep 2: Correlate with requestsStep 3: Review recordsStep 4: Take action
  • Identify slow periods
  • Note percentile spread
  • High traffic = slower
    response?
  • Specific request types
    causing issues?
  • Index size affecting
    speed?
  • Recent data imports?

Capacity Planning​

Monitor Record UsageAPI Request TrendsPerformance Benchmarks
  • Track blue vs purple line gap
  • Project growth rate
  • Plan upgrades before
    hitting limits
  • Identify peak usage times
  • Plan rate limits accordingly
  • Budget for increased usage
  • Set acceptable response
    time targets
  • Alert when degradation
    occurs
  • Proactive optimization

Important Notes​

Data AccuracyTimezone ConsiderationGraph InteractionsPerformance Context
  • Graphs update based on
    selected date range
  • Real-time data may have
    slight delay
  • Historical data is accurate
    and complete
  • All data in UTC
  • Convert to local time
    for analysis
  • Be consistent with timezone
    when comparing periods
  • Hover over points for exact
    values (if supported)
  • Click legend items to toggle
    visibility (if supported)
  • Use jump links for quick
    navigation
  • Response times affected
    by many factors
  • Network latency
  • Query complexity
  • Index size
  • Server load

Setting Alerts​

Recommended Thresholds:

RecordsResponse TimeError Rate
  • Alert when used reaches
    80% of included
  • Plan upgrade before hitting limit to ensure
    continuous service availability and prevent disruptions
  • Alert when average
    exceeds 500ms
  • Critical when 90th percentile
    exceeds 1000ms
  • Alert when errors exceed
    5% of total requests
  • Investigate immediately
    if sustained

Using Data for Decisions​

Scaling DecisionsIndex Optimization
  • Consistent high usage → Scale up (upgrade in Billing)
  • Wide gap in records → Potential downgrade (optimize in Configuration)
  • Response time degradation indicates system bottlenecks → Implement performance optimization strategies
  • Large index + slow response → Optimize schema in Configuration
  • High build frequency → Review update strategy in Configuration
  • Error patterns → Fix data quality issues (debug in API Logs)

Frequently Asked Questions​

Why are my response times showing 0ms?​

This can occur when:

  • Store is newly created with limited data
  • Very low traffic during selected period
  • Performance logging is still initializing
  • Select a longer date range for meaningful data

How far back can I view historical data?​

This depends on your plan and data retention policy. Typically:

  • Standard plans: 30-90 days
  • Enterprise plans: 1 year or more
  • Contact support for specific retention details

What causes spikes in the API requests graph?​

Common causes:

  • Scheduled index rebuilds
  • Bulk data imports
  • Marketing campaigns driving traffic
  • Automated testing or monitoring
  • System migrations

Why did my record count drop suddenly?​

Possible reasons:

  • Index rebuild or refresh (configured in Configuration)
  • Data cleanup or deletion
  • Migration to new schema
  • Temporary system maintenance
  • Check API Logs for corresponding events

How do I improve response times?​

Optimization strategies:

  1. Review and optimize query patterns in Configuration
  2. Reduce index size if over-provisioned
  3. Optimize searchable attributes in Configuration

Can I compare different time periods?​

While the UI shows one range at a time, you can:

  • Take screenshots of different periods

  • Use multiple browser tabs for side-by-side viewing

Why do graphs look different from API Logs?​

API Logs:

  • Real-time, live view
  • Shows individual requests
  • Recent activity focus

Stats:

  • Historical, aggregated data
  • Shows trends and patterns
  • Long-term analysis focus