The timetable is right. Why did the prayer alert fail?

Begin with a simple distinction: did the alert arrive late, arrive silently, or never appear? Those observations lead to different checks. They also help you explain the problem to the developer without guessing that the phone, app or operating system must be at fault.

The steps below provide a way to investigate the cause, not a promise that a particular setting will fix every app. iPhone examples use Apple’s iOS 26 guide. Android requirements are labelled by version where relevant; manufacturer menus and app implementations differ. No specific RUKN notification behaviour is assumed.

First, establish what was supposed to happen

Open the timetable and confirm the date, selected place and local clock. Check whether the app’s reminder is intended for the listed prayer time, an advance warning or a later reminder. Look for a per-prayer switch if the app offers one. Do not assume that enabling one alert enables all five.

Write down three values: the displayed prayer time, the intended reminder time and the time you actually noticed an alert. If no alert appeared, say that rather than inventing an arrival time. A screenshot can help, but remove account or location details before sending it elsewhere.

If the timetable itself differs from the reference you follow, resolve that separately using the prayer-times settings guide. This article starts from a timetable you have already checked. An alert is a reminder based on software inputs, not independent evidence that a religious time has entered.

Was there a notification, but no sound?

Check the notification list before changing anything. On iPhone, Notification Center can show older notifications. On Android, some devices provide notification history, although it is not available on every model and should not be assumed to contain records from before it was enabled. Apple’s iOS 26 notification guide, Android notification controls

If you find an entry in the list, focus next on how the notification was presented: the system has displayed something, but your desired sound or visible interruption may not have occurred. Check the app’s sound selection and the phone’s relevant sound controls. Do not treat successful music playback as proof that notification sound is configured correctly.

On supported Android devices, a notification category can be silent while other notifications from the same app are alerting. Google distinguishes silent notifications from those that produce sound and vibration. Inspect the prayer-related category, if the app provides one, rather than only its overall notification switch. Android alerting and silent notifications

This is also why a test sound inside an app is not a complete notification test. It tells you that sound played during that interaction. It does not demonstrate that a future background reminder has been scheduled, permitted and presented under your overnight settings.

On iPhone, review delivery and Focus separately

For iOS 26, Apple documents app notification controls under Settings, Notifications, then the app. Review Allow Notifications and the available sound and presentation options. If the app is included in Scheduled Summary, check whether you want its reminders delivered immediately instead. Summary delivery is designed to group notifications for later attention. Apple’s iOS 26 notification settings

Then inspect the Focus that was active at the relevant time, especially Sleep or a scheduled work Focus. Apple allows you to specify which apps may notify you during a Focus. You can make a targeted choice rather than turning off every Focus arrangement. Apple’s iOS 26 Focus controls

Do not assume an app’s “important” or “adhan” label means its alerts bypass all system controls. The app’s wording and the operating system’s treatment are different things. Check the actual notification options offered for that app and consult its support instructions if a special alert mode is mentioned.

After a change, test with the same Focus you normally use. A successful afternoon test with no Focus active does not reproduce the conditions under which a dawn reminder failed.

On Android, notifications and exact alarms are different permissions

Android 13 introduced a runtime permission for most app notifications. Declining it can prevent ordinary notifications even if the app still displays its timetable normally. Review the app’s notification permission before investigating more complex causes. Android notification permission

After checking whether notifications are allowed, consider the separate question of how the app schedules them. Android distinguishes inexact alarms, which can be delivered within scheduling windows, from exact alarms intended for precisely timed actions. The scheduling method is a developer decision; the presence of a prayer reminder does not tell you which method the app uses. Android alarm scheduling

On Android 14 and later, the SCHEDULE_EXACT_ALARM permission is denied by default for most newly installed apps targeting Android 13 or later that request it, subject to documented exceptions. Backup-and-restore can also leave that permission denied. This is not the same permission as allowing notifications. Android 14 exact-alarm change

If your app explains that its reminders require “Alarms & reminders,” follow its supported setup and inspect that specific access. Do not assume every prayer app needs the same permission or qualifies for the same exemption. Nor should you install an unofficial modified version to bypass the system’s requirements.

A missing or confusing request is worth reporting to the developer. Users cannot repair an app’s scheduling implementation by granting unrelated permissions.

Check power management only where it is relevant

If notification access and scheduling do not explain the result, check the relevant power controls next. Android’s Doze and App Standby reduce background activity. Doze can defer network access, jobs and standard alarms; Android provides specific alarm mechanisms for suitable time-sensitive work. Thus, “it arrived when I woke the phone” is a useful clue, but it is not proof that every battery feature must be disabled. Android Doze and App Standby documentation

Manufacturers can add their own controls. Samsung documents that apps placed in Deep sleeping mode do not run in the background and may receive notifications only when opened. Check the specific app’s status using guidance for your model and One UI version. Samsung battery optimisation guidance

If a targeted change is recommended by the app developer and device maker, record it and test the result. Broader background activity can have a battery cost. Keep the change limited to the app you are investigating; do not disable unrelated security, accessibility or privacy protections.

A reminder’s dependence on connectivity also needs an app-specific answer. Ask whether reminders are scheduled on the device, delivered by a server, or depend on periodically refreshing a schedule. The fact that a timetable remains visible offline does not establish how its alerts work.

Run a realistic test, then keep a useful record

Where the app has a documented test-reminder feature, use it. Otherwise observe the next genuine reminder while maintaining a separate, checked backup. Do not alter the prayer timetable just to make a test easier.

Use one change per test. Keep the phone in its normal state: screen locked, the relevant Focus or Do Not Disturb active, and the usual network arrangement. Note whether the result was a banner, a silent entry, a sound or nothing. If the failure followed a restart or travel, include that fact rather than assuming it caused the problem.

Bring those observations together in a compact report if you contact support:

• Phone model, operating-system version and app version.
• Expected reminder time and observed behaviour.
• Whether other reminders from that app worked.
• Whether the alert appeared only after opening the app or waking the phone.
• Relevant notification, Focus and app-specific power settings.
• Changes already tested and their results.

Avoid sending a complete notification history containing other people’s messages. The developer needs enough information to reproduce the failure, not your unrelated private activity.

Until you have observed reliable behaviour under the conditions that matter, keep a backup reminder based on your checked timetable. Update it as times change. Use the test record to establish what actually happens on your phone and when the remaining problem requires the developer’s help. A reassuring setting name alone cannot establish reliable delivery.