Push notifications are valuable when they help someone act at the right moment. They become a liability when they interrupt without adding enough value. The difficult part is that “too many” is not a fixed number: it depends on the user, the message, the urgency, the product, and the expectations set during permission and onboarding.

A banking alert about a suspicious transaction can justify an immediate interruption. A weekly product summary usually cannot. Treating both as equivalent notifications is a reliable way to create fatigue, disablement, and missed high-value alerts.

The right goal is not to maximise sends. It is to make every notification useful enough that people continue to allow them.

Why notification volume becomes a product problem

Every push notification has a cost. It takes attention, creates an interruption, and trains the recipient to decide whether future messages are worth opening. Repeated low-value messages can reduce trust in the whole channel, including notifications that genuinely matter.

High volume can cause several problems:

  • Users mute notifications at the operating-system level.
  • Users disable notifications in your product settings.
  • Users ignore messages, reducing the value of delivery and open metrics.
  • Users uninstall the app or associate it with unwanted interruption.
  • Important alerts become harder to notice among routine updates.

A high send count is therefore not a useful success metric on its own. A good notification programme balances reach with relevance, timing, delivery, engagement, and opt-out behaviour.

There is no universal “safe” number

A fixed rule such as “send no more than three notifications per day” can be a useful starting constraint, but it is not a complete strategy. A user actively following a live event may welcome several timely updates. Another user may find one promotional message per week excessive.

Set limits by message purpose and user expectation rather than applying one global number. A practical classification is:

  • Critical: security, account access, payment risk, service disruption, or another event where delay could cause harm.
  • Transactional: a requested action has completed, failed, changed, or requires attention.
  • Time-sensitive: a delivery window, appointment, expiring action, or event reminder.
  • Informational: a digest, recommendation, status update, or content notification.
  • Promotional: an offer, campaign, reactivation message, or sales prompt.

Critical and transactional messages may need to bypass ordinary marketing limits, but they should still be deduplicated and accurately targeted. Informational and promotional messages generally need stronger frequency controls, quiet hours, and preference management.

Build a frequency policy before adding campaigns

Start by writing down the rules that determine whether a message should be sent. Do not leave these decisions inside separate campaign implementations, where conflicts are difficult to detect.

A useful policy should answer:

  • Which notification categories can interrupt a user?
  • What is the maximum number of non-critical messages in a rolling period?
  • Do multiple campaigns share the same user-level budget?
  • What happens when two messages are eligible at the same time?
  • Which events bypass the cap, and who owns that decision?
  • Are quiet hours based on the user’s local time zone?
  • How can a user reduce or stop a category without disabling all notifications?

Rolling windows are usually more consistent than calendar-day limits. A calendar rule can allow one message just before midnight and another immediately afterwards, even though the recipient experiences them as back-to-back interruptions. A rolling limit considers the recent history of sends for that user or device.

Maintain separate budgets for different purposes where appropriate. For example, a critical account alert should not consume the same allowance as a product announcement. However, do not use category separation as an excuse to send unlimited messages. The user experiences the combined stream, not your internal taxonomy.

Prioritise messages when demand exceeds the budget

Frequency control is also a selection problem. If five messages are eligible but the user has capacity for one, choose the most valuable message rather than sending all five or relying on whichever job runs first.

A simple priority model can consider:

  • Urgency: how quickly the user needs to act.
  • Relevance: whether the message reflects the user’s current activity or preferences.
  • Consequence: what happens if the message is delayed or missed.
  • Freshness: whether the event is still meaningful when delivered.
  • Redundancy: whether another message already communicates the same information.

When several low-priority events occur together, combine them into a digest or summary. This is particularly useful for activity feeds, content recommendations, team updates, and operational events. A digest should not merely concatenate alerts; it should explain what changed and why the recipient should care.

Avoid sending a message for every internal event. Separate system events from user-facing events, then define which state changes deserve an interruption. A queue processing successfully is rarely a notification-worthy event. A failed payment that requires user action may be.

Use consent and preferences as part of the design

Permission is not a one-time acquisition metric. It is an ongoing relationship. Explain the value of notifications before requesting operating-system permission, and avoid implying that every message is urgent.

Give people useful controls, such as:

  • Categories they can enable or disable.
  • A choice between immediate alerts and digests.
  • Quiet hours or notification schedules.
  • Channel preferences where other channels are available.
  • A way to reduce promotional messages without losing security alerts.

Make these choices durable and easy to change. If a user changes preferences on one device, decide whether the setting applies to the account, device, or both, and document that behaviour internally. A device-level setting may be appropriate for a shared device; an account-level preference may be better for a person who uses several devices.

Implement delivery controls on the server

Frequency rules should be enforced before the send request reaches the push provider. The server should know the recipient, message category, eligibility time, recent send history, and suppression rules before creating a notification.

For HoneyNotify server-side sends, the request uses POST /v1/notifications with a Bearer API key and an Idempotency-Key. A notification requires a title, body, and target. Targets can address a device, user, tag, segment, or all enabled devices. These targeting choices should be treated carefully: broad targets make it easy for a campaign to exceed a user’s intended volume unless user-level suppression is applied before sending.

A robust flow looks like this:

  • Create an event with a stable identifier and notification category.
  • Resolve the intended audience and relevant preferences.
  • Check quiet hours, eligibility, frequency budgets, and suppression rules.
  • Deduplicate against the event identifier or an equivalent business key.
  • Select, combine, delay, or discard competing messages.
  • Send only the approved notification.
  • Store the decision and outcome for later analysis.

Use idempotency when retrying server-side requests. Network failures can leave the sender uncertain about whether a request was accepted. A stable Idempotency-Key helps prevent an application retry from becoming an accidental duplicate, but it does not replace campaign-level deduplication or frequency limits.

Account for devices, identities, and token changes

Frequency management is usually a user-level concern, even though delivery often occurs at device level. A person may have several devices, and a single event should not create an unwanted burst across all of them. Decide whether a notification should reach one device, every active device, or a preferred device, and make that decision explicit.

Client SDKs cover device registration, identity, token lifecycle, payload handling, and lifecycle events across iOS, Android, and Web Push. Use those lifecycle mechanisms to keep registration state current and to handle token changes rather than assuming a token remains valid indefinitely.

If you are migrating from another provider, imported OneSignal subscription IDs can remain as device IDs when matching provider tokens later register. However, token rotation or another provider environment can prevent matching. Migration logic should therefore include reconciliation, stale-device cleanup, and a verification plan. Otherwise, a frequency cap may appear correct in account-level data while duplicate or unreachable device records distort actual delivery.

Measure fatigue, not just engagement

Open rate is only one signal and can be misleading when used alone. Track outcomes across notification categories and cohorts, including:

  • Delivery and failure rates.
  • Opens or meaningful downstream actions.
  • Dismissals where the platform exposes them.
  • Preference changes and notification disablement.
  • Uninstalls or account inactivity, interpreted cautiously.
  • Time between messages and subsequent engagement.
  • Duplicate sends and messages suppressed by policy.

Look for deterioration as frequency increases. Compare users receiving different volumes while accounting for the fact that highly active users naturally generate more eligible events. A simple comparison of high-volume and low-volume groups can confuse cause and effect.

Test frequency changes with a defined guardrail. For example, evaluate whether a lower promotional cap affects purchases while also monitoring notification opt-outs and important transactional engagement. A short-term increase in clicks is not necessarily a win if it causes a larger loss of permission later.

Common mistakes

  • Counting only successful sends instead of all attempted interruptions.
  • Applying a campaign-level cap while ignoring messages from other campaigns.
  • Treating every event as equally urgent.
  • Sending duplicate reminders after retries or job replays.
  • Ignoring the recipient’s local time zone.
  • Using a single “all notifications” switch instead of meaningful categories.
  • Sending to every device without considering cross-device duplication.
  • Measuring opens without tracking opt-outs, disablement, or downstream value.
  • Assuming imported device records will always match future provider tokens.
  • Hiding frequency logic inside multiple services with no shared policy.

A practical starting point

Begin with a two-week inventory of every notification type, its trigger, audience, category, expected action, and current volume. Identify overlaps and messages with no clear user benefit.

Then introduce category-specific rules, a shared user-level budget for non-critical messages, quiet hours, stable event identifiers, and a suppression log. Review the results by cohort and notification purpose rather than relying on one overall average.

The exact thresholds should evolve as you learn. The important design decision is to make restraint an explicit part of the system, not a correction applied after users complain.

Conclusion

Push notifications are too many when their combined interruption costs more than their practical value. That threshold differs by person and purpose, so responsible teams use categories, priority, user controls, rolling limits, deduplication, and outcome-based measurement.

Design the notification stream as a product experience. Protect critical alerts, reduce routine noise, and give users control. The result is not simply fewer messages; it is a channel people are more willing to keep enabled.