Overview
PulseGrid meters targeted device deliveries, not button clicks.
Examples:
- one notification to one device = 1 delivery target
- one notification to 500 devices = 500 delivery targets
Plan controls may limit active devices, monthly deliveries, maximum audience size and delivery-log retention. Platform controls can impose stricter safety ceilings.
Setup
If Send notification is disabled:
1. Confirm Firebase is Verified.
2. Confirm at least one active device exists.
3. Confirm your project role allows sending.
If PulseGrid says sent but nothing appears:
1. Confirm the device token belongs to the connected Firebase project.
2. Confirm notification permission is allowed.
3. Confirm the web service worker or mobile background handler is correct.
4. Confirm foreground handling if the app is open.
5. Inspect Firebase/application logs.
If work stays pending:
1. Confirm Redis is running.
2. Confirm a Celery worker is running.
3. Confirm Celery Beat is running.
4. Inspect worker logs.
SDK history:
- JavaScript: await pg.push.listNotifications()
- Python: pg.push.list_notifications()
Code example
const history = await pg.push.listNotifications();
console.log(history);history = pg.push.list_notifications()
print(history)
Production processes typically include:
daphne -b 0.0.0.0 -p 8000 pulsegrid.asgi:application
celery -A pulsegrid worker --loglevel=info
celery -A pulsegrid beat --loglevel=infoNotes
FCM acceptance and visible display are different stages. PulseGrid can successfully hand a message to Firebase while a client device still suppresses it because of permission, token state or application-side notification handling.