Maintenance Push Notifications: Android 13, iOS, and Work Order Checks

Push notifications are a practical way to reach technicians during maintenance or outages, provided permissions and delivery are configured correctly. This guide shows how push works, which Android and iOS settings decide whether an alert appears, which practices keep alerts useful, and which technical checks and fixes keep delivery reliable. We built Fullyops around maintenance workflows.

En resumen:

On Android 13 and later, new installs need an in context notification permission request; denied permission or disabled channels can block alerts.

On iPhone, Focus settings or a paired Apple Watch may redirect alerts, while iOS 15 Critical Alerts bypass mute and Focus only for genuine outages.

Request permission after technicians see maintenance features, then send only urgent, actionable events, let them choose categories, and keep routine updates in dashboards.

Set message lifetime to match how long an alert remains true, and use topics to replace stale undelivered updates for the same asset.

When alerts go missing, check device permissions, channels, Focus, and battery restrictions before investigating server logs or expired subscriptions.

Fullyops

Keep Maintenance Work Moving

Manage maintenance work orders in one platform, with tools for tracking interventions, recording hours, and reviewing operational performance.

Solicite una demostración

Índice

How do push notifications reach a technician’s phone?
Which device settings decide whether an alert appears?
What makes a maintenance alert worth sending?
What must implementers get right for reliable delivery?
Why do maintenance notifications go missing, and how do you fix it?
How do you connect push alerts to maintenance workflows?
An editorial take: fix permissions before polishing the pipeline
How can Fullyops help manage maintenance alerts and follow-up?
PREGUNTAS FRECUENTES
Fuentes

How do push notifications reach a technician’s phone?

Behind every alert sits a short chain, and each link can fail. Web describes the workflow in three parts: client logic that asks for permission and subscribes, server logic that sends web push protocol requests, and a service worker that receives the push event and displays the notification. Knowing the chain lets operators ask the right question when an alert goes missing: did it fail at subscription, at the push service, or on the device?

Subscription: the page or app asks permission, the browser returns a PushSubscription object, and your server stores its endpoint.
Push service: the browser vendor’s push service receives your request and routes the message to the right client, even when the user is not on your site.
Authentication and encryption: application server keys (VAPID) identify your server, and the message payload is encrypted before it travels.
Delivery parameters: TTL, urgency and topic influence how the push service queues and prioritises a message, which matters when an outage alert competes with routine updates.

For a maintenance team, the practical point is that the sender controls only part of this chain. Permission and device settings, covered next, are the part most often overlooked. Our field managers’ playbook for technician communication covers the human side of writing alerts people act on.

Which device settings decide whether an alert appears?

Even a perfect server setup fails if the device blocks the alert. Android and iOS handle permissions differently, and both have changed in ways that affect maintenance teams.

On Android 13 (API level 33) and later, the POST_NOTIFICATIONS runtime permission is opt-in for new installs. The app must request it at runtime, and if the user denies it, most notification channels stay blocked. The Android platform documentation adds that failing to request the permission can silently block critical maintenance alerts.

To check a device, work through these steps:

iPhone: open Settings, then Notifications, and select the app. Confirm Allow Notifications is on, then choose Lock Screen, Notification Centre and Banner styles. Apple’s notification settings guide explains each option.
iOS Critical Alerts: from iOS 15, Critical Alerts can reach users even when the device is muted or in a Focus mode. Reserve them for genuine outages.
Android: open Settings, then Notifications, then App notifications, and toggle the app on. Android’s notification controls also offer history, delay and per-app options.
Android channels: inside the app’s notification settings, check each channel. A disabled “Outages” channel blocks that category while others still work.
Paired devices and Focus: on iPhone, Apple’s guidance on receiving notifications notes that Focus and Do Not Disturb change where alerts appear, and a paired Apple Watch may receive the alert instead of the phone.

Consejo profesional: Ask every technician to send one test alert to themselves during onboarding, with the phone locked and Focus switched on, so you learn about silent failures before an outage does.

What makes a maintenance alert worth sending?

Good alerts protect the permission you were granted. MDN’s web push best practices recommend asking for permission only after user interaction and limiting notifications to timely, relevant content, because browsers may require interaction before allowing the request and irrelevant messages drive opt-outs. Adjust makes the same point in a mobile context: a push permission is a privilege, so ask after users have shown engagement, not on first launch.

For maintenance and outage alerts, that translates into concrete rules:

Ask for permission after the user has opened the maintenance features, once they can see what the alerts are for.
Send only time-sensitive, actionable events, such as an asset failure, an outage or a reassigned urgent job.
Let people opt into categories, for example outages versus scheduled maintenance, so a night-shift technician is not woken by a routine reminder.
Limit frequency, and avoid notifications that require interaction unless the situation strictly demands it.
Write copy that names the event, the impact, the required action and the expected time to resolve.
Track opt-out rates by category, and move timing or content when a category starts losing subscribers.

A weak alert says “Asset update.” A strong one says “Pump offline, line B stopped, check isolation valve, ETA soon.” The second version can be acted on from the lock screen without opening anything.

Frequency deserves its own discipline. Routine status changes belong in a report or a dashboard, not in a push. Our guide on piloting three maintenance reports to avoid inbox overload shows how to move low-urgency information out of the alert channel so that real alerts keep their weight.

Consejo profesional: Run a monthly review of every alert category. If a category has more opt-outs than acknowledgements, rewrite it or retire it before it damages the whole channel.

Mobile design also shapes how alerts are read. Bold Factory’s piece on what a mobile interface for operators should include is a useful reference on validating mobile screens on the factory floor, where gloves, noise and glare change what counts as readable.

What must implementers get right for reliable delivery?

Developers and operations engineers need a short, repeatable list. Work through it in order, and treat each item as a release gate.

Generate VAPID keys once. Create the application server key pair a single time, store the private key securely, and include the public key in the client subscription flow. Rotating keys without a plan invalidates existing subscriptions.
Send encrypted web push requests. Post each request to the endpoint returned in the PushSubscription. The push service rejects unauthenticated or unencrypted traffic, so log every response code.
Set urgency to match the event. Use high urgency for immediate outages and a lower level for scheduled notices, so the push service and device can prioritise sensibly.
Set TTL deliberately. A TTL that is too long delivers a stale “pump offline” message after the pump is back, which is worse than no message. Match the TTL to how long the alert stays true.
Use topics to avoid pile-up. For recurring status updates on the same asset, a topic lets a new message replace an undelivered older one, so a technician who reconnects sees the latest state, not a pile of old ones.
Handle the push event in the service worker. The worker must listen for the push event and call showNotification(). If it does not, the browser may show a generic fallback or nothing useful.
Manage the subscription lifecycle. Capture failures, retry transient errors, and mark endpoints that return invalid-subscription responses for removal.
Plan for offline clients. Queue state changes on the server, send the current state when a device returns, and clean up subscriptions that stay unreachable.

A few judgement calls sit between the steps. Keep the payload small and put detail behind a link to the work order, because a lock screen has little room. Make the notification’s tap action open the specific job, not the app home screen. And log delivery attempts server-side with the asset and event identifier, so that when someone says “I never got it”, you can answer from evidence.

On the Android side, remember that restricted permissions carry policy weight. Google Play’s guidance on sensitive permissions notes that some permissions and APIs, such as exact alarms, are restricted, and misuse can cause compliance problems. Do not reach for a powerful permission to solve a problem that a correctly configured high-urgency push already solves.

Push is also not the only way to move assignment data. Operiva explains why push beats polling for dispatch updates, which is a helpful reference when deciding how schedule changes reach field staff.

Why do maintenance notifications go missing, and how do you fix it?

When an alert fails, work from the device outward. Most missed notifications trace to a short list of causes:

Permission denied or revoked: guide the user to the system settings for the app and re-enable notifications there, since the app cannot override a denial.
No POST_NOTIFICATIONS request on Android 13 and later: confirm the app asks in context, and check that notification channels are not disabled individually.
Focus, Do Not Disturb or paired devices: check the Focus mode on iPhone and whether the alert is landing on an Apple Watch instead of the phone.
Dead subscriptions: an expired endpoint, an encryption or authentication error, or a push service response that flags an invalid subscription means the subscription must be refreshed or removed.
Manufacturer restrictions: some Android devices apply background limits and battery optimisation that delay or drop messages. Check the battery settings for the app and exempt it where policy allows.

Start with the cheapest check, the device settings, before opening server logs. In our experience of how maintenance teams work, the phone is the more common culprit than the code.

How do you connect push alerts to maintenance workflows?

The decision that matters most is organisational: define which events generate a push and which also open a work order automatically. An outage on a critical asset might do both, while a low-priority inspection reminder creates a work order and no push. Map each event, give it a content template, set an escalation path for alerts nobody acknowledges, and keep a log for audit. Our guide to mobile solutions in field service shows where this fits in a wider mobile strategy, and our proceso de gestión de órdenes de trabajo covers how alerts become tracked jobs. We bring this approach to every Fullyops deployment, from event mapping to audit trails.

An editorial take: fix permissions before polishing the pipeline

Most advice on this topic starts with the server: keys, encryption, retries. That is the easy part, and it is well documented. The failures that hurt maintenance teams happen earlier and lower down: a technician who tapped “Don’t allow” on day one, a Focus mode nobody remembers setting, an Android 13 install where the permission prompt never appeared.

So prioritise in this order. First, make permission a designed moment: ask after the user has seen what the alerts do, and explain the outage use case in plain words. Second, audit categories and channels so that a single disabled switch cannot silence the alerts that matter. Third, keep the alert list short enough that people trust it. A channel that fires for everything trains people to ignore it, and no technical checklist repairs that.

I would also be wary of treating Critical Alerts as a cure. They are powerful, but overusing them spends goodwill fast. Reserve them for events where a missed alert has a real cost, and handle everything else with ordinary priority.

— Pedro

How can Fullyops help manage maintenance alerts and follow-up?

An alert is only the start of the job. We designed Fullyops to support maintenance workflows. Teams can choose the plan that matches their size and complexity:

Basic, Professional and Advanced plans, built around the different needs of technicians, administrators and managers.
Work order management, preventive scheduling, inventory tracking and operational reporting on one platform.
Integrations and API access to connect the systems you already run.

If you are mapping alerts to a maintenance process, read our field service management overview, then see the Fullyops plans.

PREGUNTAS FRECUENTES

What are push notifications?

Push notifications are short messages a server sends to a user’s device, even when the app or site is not open. A subscription, a push service and a service worker work together to deliver and display them. Web.dev’s overview describes this workflow.

How do you enable push notifications on a phone?

On iPhone, go to Settings, then Notifications, select the app and turn on Allow Notifications. On Android, go to Settings, then Notifications, then App notifications, and toggle the app on. The exact labels vary slightly by manufacturer and version.

Why do Android 13 phones not show notifications from a new app?

Android 13 made notification permission opt-in for new installs, so an app must request the POST_NOTIFICATIONS permission at runtime. If the user denies the prompt, most notification channels remain blocked. Re-enable them in the app’s notification settings, as the Android developer guidance explains.

How often should maintenance push notifications be sent?

Send only when an event is time-sensitive and actionable, and let users choose categories. Routine updates belong in reports or dashboards. Watch opt-out rates by category and reduce frequency where they rise.