Usage data limits: 7 caps to check before a feed breaks

Requests can have a maximum of 25 events, according to Google for Developers. Keep each request under 1 MB with fewer than 2000 events, according to Amplitude. These two figures define the immediate boundaries for a usage data feed. A CSM should verify that the current feed stays within these specific caps before investigating other properties. The Google figure applies to the Measurement Protocol events sent to Google Analytics. The Amplitude figure applies to the HTTP V2 API. Each limit belongs to its named publisher and does not apply to every tool or plan. Do not treat one publisher's rule as every firm's rule.

Start by counting the events in a single request from your feed. Compare that count to the 25-event maximum for Google. Then compare it to the 2000-event expectation for Amplitude. Also check the total size of the request body. The Amplitude documentation specifies keeping this under 1 MB. If your feed exceeds these numbers, its requests exceed the stated limits. This check identifies where the feed could be cut off. It does not determine health score outcomes or churn. It only confirms whether the data transmission fits within the stated technical limits.

Check request size and event counts first to prevent feed interruptions. Amplitude advises keeping each request under 1 MB with fewer than 2000 events, according to Amplitude. Google allows a maximum of 25 events in each request, according to Google for Developers.

1. Amplitude request limits: Keep each request under 1 MB and below 2000 events, according to Amplitude.
2. Amplitude user update rate: Individual users are rate limited if they update user properties more than 1800 times per hour, according to Amplitude.
3. Google event caps: Requests can hold a maximum of 25 events, according to Google for Developers.
4. Google name and size limits: User property names must be 24 characters or fewer, and the post body must be smaller than 130kB, according to Google for Developers.
5. Pendo property size: An error property is generated when event property maps exceed 25KB or the configured MaxEventPropertyBytes, according to Pendo.
6. PostHog batch size: The entire request body must be less than 20MB by default, according to PostHog.
7. Jira board display cap: An error message appears if a board tries to display more than 5,000 work items at once, according to Atlassian.

Verify your feed against these specific figures before relying on health scores. Record the date you check each limit. Each figure applies to the specific publisher named; do not assume one publisher's rule applies to every tool or plan. Focus on the metrics that directly impact your data ingestion pipeline.

Count the events in each request and measure the longest property name in your current usage feed, then compare them with the Google and Amplitude figures in the table.

The HTTP V2 API documentation from Amplitude defines several distinct measurement points for data ingestion. First, it sets a rate limit for individual users, specifically those identified by an Amplitude ID, who update their user properties more than 1800 times per hour. This figure measures the frequency of user property changes rather than event volume. Second, Amplitude expects fewer than 100 batches each second, with a limit of 1000 events each second. This metric tracks the throughput of data packets and individual events within a single second.

Third, keep each request under 1 MB with fewer than 2000 events. This figure measures the physical size of the HTTP payload and the count of events contained within that single request. Fourth, the SDK endpoint supports up to 150,000 events each second for each project. This measures the maximum throughput capacity available through the SDK interface, which differs from the HTTP V2 limits.

Finally, the source establishes a string length cap, stating that all string values, like user_id, event, or user property values, have a character limit of 1024 characters. This figure measures the maximum length of any text field within the data structure. Each of these figures measures a different aspect of the data feed: user update frequency, batch throughput, request payload size, SDK throughput, and string length. Understanding which metric applies to which part of your feed is necessary before comparing your data against these published figures. It presents them as separate constraints on different dimensions of the data flow. Your feed may hit the request size limit before the event count limit, or the string length limit before the batch rate limit. Identifying which specific metric your feed is closest to requires measuring each dimension independently.

The table below lists the specific caps for each publisher. Use the "Value" column to check your feed against the stated limit.

Amplitude rate limits individual users (by Amplitude ID) that update their user properties more than 1800 times per hour, according to Amplitude. Amplitude expects fewer than 100 batches each second, and the limit of 1000 events each second still applies, according to Amplitude. For comparison, the SDK endpoint supports up to 150,000 events each second for each project, according to Amplitude. All string values, like user_id, event, or user property values, have a character limit of 1024 characters, according to Amplitude.

Google for Developers documentation states that events and user properties can be backdated up to 72 hours, according to Google for Developers.

Pendo automatically generates a property named error when submitted event property maps exceed 25KB or the application's configured MaxEventPropertyBytes, according to Pendo. There is no limit on the number of events you can send in a batch, but the entire request body must be less than 20MB by default, according to PostHog. Due to the reduced cost of processing them, anonymous events can be up to 4x cheaper than identified ones, so we recommended you only capture identified events when needed, according to PostHog.

To verify your usage feed against the Google for Developers standards, start by counting the events in a single request. The documentation states that requests can have a maximum of 25 events according to Google for Developers. If your batch contains more than this number, the request exceeds the specified limit. Next, examine the parameters attached to each individual event. Events can have a maximum of 25 parameters according to Google for Developers. Review your event schema to ensure no single event carries more than twenty-five distinct parameters.

Check the user properties associated with your events. List the user properties in your current feed and confirm the count stays at or below this threshold. Measure the length of your user property names. User property names must be 24 characters or fewer according to Google for Developers. Identify any names in your data that exceed this character count and shorten them.

Evaluate the length of your user property values. User property values must be 36 characters or fewer according to Google for Developers. Scan your data for values longer than thirty-six characters. Finally, check the total size of your post body. The post body must be smaller than 130kB according to Google for Developers. Calculate the byte size of your outgoing requests to ensure they remain under this limit.

Consider the timing of your data submission. Events and user properties can be backdated up to 72 hours according to Google for Developers. If your feed sends data older than this window, it falls outside the documented backdating capability. Note your own check date to maintain a clear record of when you verified these limits.

If your feed uses a different analytics provider, these specific Google for Developers figures do not apply to that tool. Do not assume these caps govern other platforms. Focus your review on the specific provider your health score relies on. For tools using the Measurement Protocol, align your event structure with the 25-event request limit and the 25-parameter event limit. Keep user property names at 24 characters or fewer and user property values at 36 characters or fewer. Ensure your post body stays under 130kB.

When your data pipeline includes delayed events, verify the delay does not exceed the 72-hour backdating window. If it does, the events may not be accepted as backdated. Adjust your pipeline to send data within this timeframe. Document any discrepancies between your current feed and these limits. Use this documentation to guide adjustments to your data collection strategy.

The Pendo limit applies specifically to the size of the submitted event property map. When that map exceeds 25KB or the application's configured MaxEventPropertyBytes, the system automatically generates a property named error, according to Pendo. For Pendo event property maps, check the 25KB threshold or the application's configured MaxEventPropertyBytes.

PostHog documentation states there is no limit on the number of events you can send in a batch, but the entire request body must be less than 20MB by default, according to PostHog. A request body exceeding this cap must be reduced to comply with the size limit. The same source notes that due to the reduced cost of processing them, anonymous events can be up to 4x cheaper than identified ones, so it is recommended to only capture identified events when needed, according to PostHog. This cost distinction stops being useful if your feed does not distinguish between anonymous and identified events, as the pricing benefit applies specifically to the processing of anonymous data.

The Jira board display cap is distinct from analytics limits. If a board is trying to display more than 5,000 work items at once, you'll receive an error message, and be prompted to update your filters, according to Atlassian. This figure stops being useful for usage data feed analysis because it concerns the display of work items on a board, not the ingestion of event data. It does not apply to event payload sizes or the number of properties in each event.

Check your current feed's property map sizes against the 25KB threshold and verify your request body sizes stay under 20MB.

• Onboarding tools: compare 4 customer project plans
• Health score setup: 8 rules for weights and validity
• NPS survey configuration: 5 checks before launch

What usage data limits should I check first?

Check request size and event counts first. Amplitude docs advise keeping each request under 1 MB with fewer than 2000 events Amplitude. Google for Developers states requests can have a maximum of 25 events Google for Developers. Verify your current feed against these two figures before checking other limits.

How many events can a Google request hold?

A Google request can hold a maximum of 25 events according to Google for Developers. This limit applies to the number of events included in a single request. If your feed batches more than 25 events in a request, split the batch to comply with this figure.

Does the Amplitude limit apply to my own project or plan?

The 1800 times per hour rate limit applies to individual users by Amplitude ID, not necessarily the whole project according to Amplitude. Amplitude rate limits individual users that update their user properties more than 1800 times per hour. Check if any single user ID in your feed exceeds this update frequency.

How long can a Google user property name be?

Ensure all property names in your usage feed meet this length requirement. Rename any property exceeding 24 characters to prevent data loss.

Can usage events be backdated, and by how long?

This window applies to both event timestamps and user property updates. Do not attempt to backdate events older than 72 hours in your feed.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.