> ## Documentation Index
> Fetch the complete documentation index at: https://buttercms.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring API usage

> Use the ButterCMS Analytics dashboard to monitor API traffic, understand usage patterns, and plan capacity for your content delivery needs.

## The Analytics dashboard

The dashboard includes key usage metrics:

* **Users** - Number of users in your account
* **Pages** - Total pages created
* **Blog Posts** - Total blog posts created
* **Collections** - Total collections created
* **Read API Requests** - API calls fetching content
* **Write API Requests** - API calls creating, updating, or deleting content

API request limits vary by plan. See [Plan Features](../../support/account-management/pricing-plans) for specific limits.

Each metric supports:

* **Line, Area, and Bar** chart views
* **Running Total** toggle for cumulative trends

## Accessing the Analytics dashboard

To access the dashboard:

1. Log in to ButterCMS
2. Select **Analytics** on the navigation menu
3. Your real-time charts and filters will appear immediately

No configuration or additional permissions are required.

{/* IMAGE_SOURCE: file_path="knowledge-base/how-to/get-real-time-insights-with-buttercms-analytics.md" */}

![Analytics inside ButterCMS Menu](https://cdn.buttercms.com/XkEGiB9PS8KXgJpmN9aV)

## Understanding your usage metrics

![Analytics chart view](https://cdn.buttercms.com/ukh501JRrmeqOHsoj3iq)

### Read API requests

Read API requests are calls that fetch content from ButterCMS:

* `GET /v2/posts/` - Listing blog posts
* `GET /v2/pages/{page_type}/{slug}/` - Retrieving pages
* `GET /v2/content/` - Fetching collections
* `GET /v2/authors/` - Listing authors
* `GET /v2/categories/` - Listing categories

**Optimization tip:** Read requests served from CDN cache don't count against your API limits.

### Write API requests

Write API requests create, update, or delete content:

* `POST /v2/pages/` - Creating pages
* `PUT/PATCH /v2/pages/{page_type}/{slug}/` - Updating pages
* `DELETE /v2/pages/{page_type}/{slug}/` - Deleting pages
* `POST /v2/posts/` - Creating blog posts
* `POST /v2/content/{collection_key}/` - Creating collection items

### Why monitoring matters

This quick-glance overview helps your team:

* **Stay within plan limits** tied to your subscription
* **Monitor API usage** to prevent overages
* **Maintain content hygiene** across environments

Understanding your content usage helps you plan smarter and avoid potential interruptions.

## Filtering and customizing your view

Use filters to narrow or expand exactly what you want to see:

* **Site** - View a specific site or opt-in to view all sites
* **Environments** - Development, staging, and production
* **Date Range**:
  * Month to Date
  * Previous Month
  * Last 12 Months
  * Custom Range
* **Aggregation** - Daily, Weekly, Monthly, or Yearly

These filters help you explore both high-level patterns and narrow operational issues.

## Exporting your data

You can export your filtered dashboard results as a CSV file for reporting or further analysis. Exports include:

* Site and Environment
* All visible KPI metrics
* Data grouped by the selected aggregation (daily / weekly / monthly / yearly)

This makes it easy to integrate Butter usage data into your existing analytics workflows and stack.

## Who benefits from Analytics?

### For developers and technical leads

Get instant visibility into API activity, content volume, and environment-specific usage. Quickly identify spikes, monitor deployment hygiene, and export data for system monitoring tools.

### For marketers and content teams

See how your content is growing over time. Track pages, posts, and collections to plan launches, support campaigns, and manage day-to-day content operations, all with simple, self-serve analytics.

### For partners and agencies

Review API traffic and content activity across client projects in one place, share real-time insights with clients, and ensure environments stay healthy throughout development and as they evolve.

## Interpreting usage patterns

### Identifying normal vs. abnormal usage

| Pattern                     | Likely Cause                   | Action              |
| --------------------------- | ------------------------------ | ------------------- |
| Steady daily usage          | Normal production traffic      | Monitor for trends  |
| Spikes during work hours    | Content team activity          | Expected behavior   |
| Large spike after deploy    | Cache invalidation / rebuilds  | Consider staggering |
| Unexpected nighttime spikes | Bot traffic or runaway process | Investigate         |
| Gradual increase over weeks | Growing traffic                | Plan for capacity   |

### Common usage patterns by integration type

**Static Site Generation (SSG):**

* Bursts during build time
* Low usage between builds
* Spikes when webhooks trigger rebuilds

**Server-Side Rendering (SSR):**

* More consistent usage throughout day
* Correlates with website traffic
* Should leverage caching to reduce calls

**Client-Side (SPA):**

* Usage correlates directly with page views
* Each visitor may make API calls
* Consider edge caching or BFF pattern

## Setting up usage alerts

While ButterCMS doesn't have built-in alerting, you can set up monitoring in your application:

### Application-level monitoring

```javascript theme={null}
// Track API calls in your application
const apiCallCounter = {
  read: 0,
  write: 0,
  lastReset: Date.now()
};

// Wrapper function that tracks calls
async function trackedApiCall(type, fn) {
  apiCallCounter[type]++;

  // Log warning if approaching limits
  if (apiCallCounter.read > 90000) { // 90% of 100K limit (Basic plan example)
    console.warn('Approaching Read API limit!');
    // Send alert to your monitoring system
  }

  return fn();
}

// Usage
const posts = await trackedApiCall('read', () =>
  butter.post.list({ page_size: 10 })
);
```

### Integration with monitoring tools

Export your ButterCMS analytics data and integrate with:

* **Datadog** - Custom metrics and dashboards
* **New Relic** - Application performance monitoring
* **Grafana** - Visualization of usage trends
* **PagerDuty** - Alerting when thresholds are exceeded

```javascript theme={null}
// Example: Send metrics to Datadog
const { StatsD } = require('hot-shots');
const dogstatsd = new StatsD();

function trackApiUsage(type, count) {
  dogstatsd.gauge(`buttercms.api.${type}_requests`, count, {
    environment: process.env.NODE_ENV
  });
}
```

## Optimizing based on usage data

### High Read API usage

If you're seeing high Read API usage, consider:

1. [**Implement caching**](./caching-strategies) at the application level
2. [**Use SSG**](./caching-strategies) instead of SSR where possible
3. [**Leverage webhooks**](../webhooks-events/cache-invalidation-webhooks) to invalidate cache instead of polling
4. [**Optimize queries**](./query-optimization) with `exclude_body` and `levels` parameters

### High Write API usage

If you're seeing high Write API usage, consider:

1. **Batch content updates** when possible
2. **Review automation scripts** for unnecessary writes
3. **Audit webhook integrations** that create content
4. **Consider using bulk operations** for migrations

## Usage optimization checklist

<AccordionGroup>
  <Accordion title="Weekly review">
    * [ ] Check current usage vs. plan limits
    * [ ] Review any unexpected spikes
    * [ ] Compare week-over-week trends
    * [ ] Identify top API consuming features
  </Accordion>

  <Accordion title="Monthly review">
    * [ ] Export usage data for records
    * [ ] Calculate average daily usage
    * [ ] Project next month's usage
    * [ ] Evaluate if plan upgrade needed
  </Accordion>

  <Accordion title="Before high-traffic events">
    * [ ] Review current usage headroom
    * [ ] Verify caching is properly configured
    * [ ] Test application under load
    * [ ] [Contact support](../../support/contact-status/contact-support) if expecting unusual traffic
  </Accordion>
</AccordionGroup>

## Environment-specific usage

### Managing multi-environment usage

If you have multiple environments (development, staging, production):

| Environment | Typical Usage           | Best Practices                  |
| ----------- | ----------------------- | ------------------------------- |
| Development | Variable, burst traffic | Use mock data when possible     |
| Staging     | Testing bursts          | Reset caches between test runs  |
| Production  | Steady, predictable     | Implement full caching strategy |

### Development environment tips

* Use local caching to minimize API calls during development
* Consider mock data for UI development
* Only fetch from API when testing integration

```javascript theme={null}
// Development-only caching
const isDev = process.env.NODE_ENV === 'development';

async function getContent(slug) {
  if (isDev && cache.has(slug)) {
    return cache.get(slug); // Return cached during dev
  }

  const content = await butter.page.retrieve('*', slug);

  if (isDev) {
    cache.set(slug, content); // Cache indefinitely in dev
  }

  return content;
}
```
