## TL;DR
Notification delay lives in one of four places: the event pipeline (queue backlog), the push provider (throttling), the device (battery optimization killing background delivery), or the user's settings (quiet hours, focus modes). Check server-side timestamps first: if the notification left your system late, it is your pipeline. If it left on time and arrived late, it is the provider or the device.

## The query

```text
notifications are delayed: troubleshooting
```

## Use this when

- Users report late notifications
- Notification reliability investigations
- Writing notification troubleshooting docs
- "I got the alert an hour late" tickets

## Not for

- Building notification systems
- Push provider initial setup
- Marketing email send-time optimization
- SMS carrier negotiations

## Steps

### 1. Compare the event time to the send time

Pull the timestamps: when the event happened, when your system sent the notification. If the gap is server-side, the problem is your queue or worker backlog. This one check splits the problem in half.

Expected output: server-side delay confirmed or ruled out.

### 2. Check for queue backlog and retries

Look at the notification queue depth and retry rates around the incident time. Backlogs from deploys, traffic spikes, or a stuck worker delay everything uniformly. Retries with backoff look like delays to users.

Expected output: queue health at the incident time.

### 3. Check the provider and platform layer

Push providers throttle; APNs and FCM have their own delivery quirks and outages. Check provider status and your throttle/error rates. Platform matters too: Android battery optimization and iOS background limits delay or batch deliveries.

Expected output: provider/platform cause identified or ruled out.

### 4. Check the user's device and settings

Focus modes, do-not-disturb schedules, notification permissions per app, and battery-saver modes. Ask the user to check these before concluding anything systemic. A phone in focus mode until 9am "delays" every 7am notification.

Expected output: device settings verified.

## Template: the troubleshooting reply

```text
Late notifications are annoying, [Name]. Let us find where the delay is:

1. I checked our side: the alert for [event] left our system at [time]. [If late: we had a backlog at that time; it is cleared now. If on time: it left us promptly, so the delay happened after.]
2. Quick checks on your phone:
   - Do Not Disturb or a Focus mode scheduled? Those hold notifications until they end.
   - Battery saver on? It can delay background notifications.
   - Notifications allowed for [app]? Worth re-confirming after OS updates.
3. What kind of delay are we talking about: minutes or hours? And is it every notification or specific ones?

Your answers will tell me exactly where to look next.
```

## Variant phrasings

### push notifications late

Steps 1 and 3. Timestamps, then provider and platform.

### email notifications delayed

Steps 1 and 2. Queue backlog is the usual suspect.

### alerts arriving hours late

Full sequence. The device-settings check surprises people.

## Why it works

Delay has a location, and the timestamps reveal it. Support teams waste hours when they start at the device (user-side) for a server-side backlog, or debug the pipeline for a focus-mode setting. The event-to-send comparison is the single highest-value check.

## Edge cases

- Delayed only for one notification type: check that type's separate queue or provider config.
- Delays after app updates: the update may have reset permissions. Re-verify settings.
- Corporate devices with MDM: the MDM policy can restrict background activity beyond user control.
- "Delayed" meaning batched: some platforms batch low-priority notifications by design. Check priority classification.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jAiUPFnwuJ2X2-X2c82C1Q