A complete record of past incidents and scheduled maintenance.
September 2026
On the morning of September 25, 2026, the automatic update process for gablvm.org applied a new release of a page rendering library that turned out to break every page. The process detected this within seconds through its own test requests and restored the previous version each time, in about thirty seconds, but it repeated the attempt at 8:30, 8:45, 9:00 and 9:15 AM Central before it was stopped. Our server logs show that every error response in those windows went to the update process itself, and none to a visitor, a search engine or the GABLVM app. No data was affected. The upstream fix was released on September 26, and the site now runs the updated library normally. The update process was also changed so a version that fails its test is not tried again.
Sep 25, 2026
minor
5 updates
investigating
We are currently investigating an alert from our automated update process. A library update applied to gablvm.org failed its post-update page test and was rolled back automatically. The site is serving pages normally while we investigate.
Sep 25, 13:31 UTC
identified
The issue has been identified. A new release of the page rendering library used by the site fails inside every page template, and the update process had retried it three more times, rolling back each time. A fix is being implemented.
Sep 25, 14:13 UTC
monitoring
A fix has been implemented and we are monitoring the results. The library release has been blocked from being installed, and the update process was watched skipping it while continuing with other updates.
Sep 25, 14:18 UTC
resolved
This incident has been resolved. The update process now remembers a release that fails its test and leaves it alone until a newer one appears. Log review found no visitor requests among the error responses; every error went to the update process itself. The library stays held at its previous release until the upstream fix is published.
Sep 25, 14:21 UTC
update
Follow-up: the upstream fix was released in Drupal 11.4.8 on September 26. Our update process applied it, the hold on the library was removed, and gablvm.org has been running the new library version normally since 5:08 PM Central.
Sep 26, 22:08 UTC
Planned work on the delivery of Quran audio on Thursday 17 September 2026, between 5:00 PM and 5:30 PM Central Time, which is 22:00 to 22:30 UTC. During this window, playing or downloading Quran audio on gablvm.org or in the GABLVM iOS app may briefly fail or need to be started again. Prayer times, the calendar, community events and the rest of the site are unaffected, and no data is affected. The work itself is expected to take only a few minutes of the window, and this notice will be updated when it begins and again when it is complete.
Sep 16, 2026
to Sep 17, 2026
maintenance
3 updates
scheduled
This maintenance is scheduled for Thursday 17 September 2026, 5:00 PM to 5:30 PM Central Time. Quran audio may be briefly unavailable during the window.
Sep 16, 11:55 UTC
in_progress
This maintenance was moved earlier and began at 9:40 AM Central Time on Thursday 17 September 2026. Quran audio is playing normally, and we will post here when the work is finished.
Sep 17, 14:40 UTC
completed
This maintenance is finished. It was completed on the morning of Thursday 17 September 2026, ahead of the planned window, and Quran audio was not interrupted at any point. No action is needed.
Sep 17, 14:50 UTC
In the Quran player on gablvm.org and in the GABLVM iOS app, available to testers through TestFlight, playing a surah verse by verse with the English translation switched on could cut short the end of some verses for the reciter Abdurrahman As-Sudais before the translation started, most noticeably in the short surahs. During the investigation we also found that the English translation clips carried a faint background tone in the pause before the narrator speaks. Chapter playback, other reciters, and playback without the translation were unaffected, and no data was affected. Both issues trace to how the source recordings were cut into per-verse clips rather than to a failure of our systems. The player is being changed to keep together the verses this reciter recites in one breath, and the translation clips are being re-cut with the tone removed. These issues have been present since verse-by-verse English playback was introduced.
Sep 15, 2026
to Sep 16, 2026
minor
9 updates
investigating
We are currently investigating a report that, in verse-by-verse playback with the English translation switched on, some verses for the reciter Abdurrahman As-Sudais end abruptly before the translation starts.
Sep 15, 08:25 UTC
identified
The issue has been identified and a fix is being implemented. During the investigation a faint background tone was also found in the English translation clips, and it is being corrected at the same time.
Sep 15, 09:05 UTC
update
We are continuing to work on this issue. The change to how the player groups verses is in place on gablvm.org for testing, and the re-cut English translation clips are being prepared. A further update will follow once they are live.
Sep 15, 10:12 UTC
monitoring
A fix has been implemented and we are monitoring the results. The re-cut English translation clips are live on gablvm.org, and the change that keeps this reciter's verses together is available there for testing. A visitor who still hears the old clips can reload the page. The GABLVM iOS app receives both changes in its next TestFlight build.
Sep 15, 10:21 UTC
resolved
This incident has been resolved. The re-cut English translation clips and the change that keeps this reciter's verses together are live on gablvm.org, and the GABLVM iOS app carries both in build 27, delivered to testers through TestFlight.
Sep 16, 02:08 UTC
update
This incident has been reopened. Testing of build 27 in the GABLVM iOS app found that a short gap could still be heard inside a group of verses for this reciter, and that the pause after each English translation clip was longer than on gablvm.org. The website was unaffected.
Sep 16, 02:22 UTC
identified
The cause has been identified: the app plays each verse clip as a separate item and cannot join two clips as seamlessly as the website does. Each group of verses is being prepared as one continuous clip, and the English translation clips are being re-cut with a shorter pause.
Sep 16, 02:36 UTC
monitoring
A fix has been implemented and we are monitoring the results. The re-cut English translation clips and the continuous clips for each group of verses are live, and build 28 of the GABLVM iOS app, which plays them, has been delivered to testers through TestFlight.
Sep 16, 07:58 UTC
resolved
This incident has been resolved. Build 28 has been confirmed on a device: verses for this reciter play complete and without a gap, and the English translation follows each group of verses. The change on gablvm.org has been in place since 15 September.
Sep 16, 08:11 UTC
In the GABLVM iOS app, available to testers through TestFlight, downloading a surah together with its English translation could stop partway through with a message that the audio server returned an error, after roughly a third of the translation files had been saved. Streaming playback, downloads without the translation, and the Quran player on gablvm.org were unaffected, and no data was affected. The cause was a request limit on our audio delivery service that also counted the app's bulk translation download; the limit has been adjusted so these downloads complete, and a download that failed can simply be started again. The failure was intermittent and may have occurred at any time since translation downloads were introduced.
Sep 12, 2026
minor
4 updates
investigating
We are currently investigating a report that downloading a surah with its English translation in the GABLVM iOS app fails partway through with an audio server error.
Sep 12, 17:30 UTC
identified
The issue has been identified and a fix is being implemented.
Sep 12, 17:36 UTC
monitoring
A fix has been implemented and we are monitoring the results. A download that failed can be started again.
Sep 12, 17:39 UTC
resolved
This incident has been resolved.
Sep 12, 17:40 UTC
August 2026
On forms across gablvm.org, including the contact form, screen readers could announce a required field as containing invalid data the moment a page loaded, before the visitor had entered anything. VoiceOver on iPhone and Mac was the most affected, hearing invalid data on fields that were simply empty. Every form remained fully usable throughout: options could be selected, steps advanced, and submissions completed normally, and no data was affected. The way required fields are marked has been reworked so screen readers now announce them as required rather than invalid. The behavior was likely present since the contact form launched in early July.
Aug 31, 2026
minor
4 updates
investigating
We are currently investigating a report that screen readers announce some form fields as invalid before any information has been entered.
Aug 31, 19:52 UTC
identified
The issue has been identified and a fix is being implemented.
Aug 31, 20:12 UTC
monitoring
A fix has been implemented and we are monitoring the results.
Aug 31, 20:14 UTC
resolved
This incident has been resolved.
Aug 31, 20:16 UTC
Since the Mute control was added to the Quran player, it was displayed at the far left of the playback toolbar while keyboard focus and screen reader reading order reached it last, after Skip forward 30 seconds. Sighted keyboard users saw Mute first but had to Tab past every other control to reach it, and people using a screen reader with sight heard the controls in a different order from the one on screen. Every control worked normally throughout, playback was unaffected, and no data was affected. The toolbar now displays the controls in the same order they are reached by keyboard and screen reader: Skip back 30, Skip back 10, Play or Pause, Skip forward 10, Skip forward 30, Mute.
Aug 29, 2026
to Aug 30, 2026
minor
4 updates
investigating
During a routine screen reader review of gablvm.org we noticed that the Quran player's Mute control appeared in a different position on screen than the position it is reached in by keyboard and screen reader. We are investigating.
Aug 29, 08:50 UTC
identified
The issue has been identified as a display ordering setting on the playback toolbar that placed the Mute control first on screen while it remains last in the keyboard and reading order. A fix is being implemented.
Aug 29, 08:51 UTC
monitoring
A fix has been implemented and we are monitoring the results. Visitors who still see Mute at the left of the toolbar can reload the page.
Aug 30, 06:44 UTC
resolved
This incident has been resolved. The Mute control now appears last on the toolbar, matching the keyboard and screen reader order on all devices. The mismatch had been present since the control was introduced; it affected the order of the controls only, never their function.
Aug 30, 06:47 UTC
Since June 26, the Quran player's single-key keyboard shortcuts, such as K to play or pause and J and L to skip backward and forward, did not respond while keyboard focus was on the player's control bar. Because the control bar is where keyboard focus naturally rests during listening, keyboard and screen reader users on all devices were affected. The on-screen buttons, arrow-key navigation between controls, and playback itself worked normally throughout, and no data was affected. The shortcuts were silenced by a side effect of a June 26 accessibility improvement made for Windows screen reader users. A listener report on August 16 led us to the cause, and a fix was deployed the same day restoring the shortcuts while keeping the improved control bar.
Aug 16, 2026
minor
4 updates
investigating
We are currently investigating a report that the Quran player's single-key keyboard shortcuts, including K to play or pause, do not respond while keyboard focus is on the playback controls.
Aug 16, 14:45 UTC
identified
The issue has been identified and a fix is being implemented. The shortcuts stopped responding after a June 26 update to the playback controls; playback and the on-screen buttons are unaffected.
Aug 16, 14:48 UTC
monitoring
A fix has been implemented and we are monitoring the results. Reload the player page to pick up the update.
Aug 16, 15:03 UTC
resolved
This incident has been resolved. The single-key shortcuts respond again while focus is on the playback controls, on all devices, and the control bar improvements from June remain in place.
Aug 16, 15:04 UTC
During three brief windows overnight, visitors to gablvm.org may have received a stale cached response from our content delivery layer instead of the requested page. Each window lasted about ten minutes or less and cleared automatically, and most visitors were unaffected. A fault in our automated cache recovery process was identified and corrected the same morning.
Aug 15, 2026
minor
4 updates
investigating
We are currently investigating an alert from our automated monitoring regarding a stale cached response being served on gablvm.org.
Aug 15, 02:34 UTC
identified
The issue has been identified as a fault in our automated cache recovery process and a fix is being implemented.
Aug 15, 06:58 UTC
monitoring
A fix has been implemented and we are monitoring the results.
Aug 15, 07:07 UTC
resolved
This incident has been resolved. Three brief recurrences occurred between 02:34 and 04:56 UTC, each clearing within about ten minutes. A fault in our automated cache recovery process has been corrected.
Aug 15, 07:14 UTC
For roughly 46 minutes on August 14 (from about 21:29 to 22:15 UTC), a portion of visitors who were not signed in were shown a repeating loading page reading "One moment, please" instead of the requested page. The site itself remained fully operational throughout, signed-in visitors were unaffected, and no data was involved; the loading page came from a stale cached response in our content delivery layer. The cache was cleared to restore normal access immediately, and we have since shortened how long pages may be cached and added automated monitoring that detects and clears this condition within minutes if it ever recurs.
Aug 14, 2026
minor
4 updates
investigating
We are currently investigating a report that some visitors are shown a repeating loading page reading "One moment, please" instead of the requested page.
Aug 14, 22:08 UTC
identified
The issue has been identified and a fix is being implemented. A stale cached response in our content delivery layer was being served to a portion of visitors who were not signed in.
Aug 14, 22:14 UTC
monitoring
A fix has been implemented and we are monitoring the results. The affected cache has been cleared, and normal page delivery has been confirmed. Any visitor still seeing the loading page should reload the page.
Aug 14, 22:16 UTC
resolved
This incident has been resolved. Pages are now cached for a shorter period, and automated monitoring is in place to detect and clear this condition within minutes if it ever recurs.
Aug 14, 22:28 UTC
Screen reader users on some devices may not hear the question above a set of multiple-choice answer options announced before the options themselves on gablvm.org forms, including the community research form. All questions, options, and form submissions continue to work normally, and the question text remains reachable by moving backward one step from the options. An initial fix was deployed on August 7 and did not fully resolve the behavior; a revised fix is in progress.
Aug 6, 2026
to Aug 7, 2026
minor
6 updates
investigating
We are currently investigating a report that the question above multiple-choice answer options on gablvm.org forms is not announced by the VoiceOver screen reader before the options are read. Forms continue to accept and record submissions normally.
Aug 6, 10:10 UTC
identified
The issue has been identified as a theme-level styling interaction that can prevent some screen readers from announcing the group question, and a fix is being implemented.
Aug 7, 12:02 UTC
update
An initial fix has been deployed and all caches have been cleared. We are verifying the change with screen reader testing on affected devices.
Aug 7, 12:14 UTC
update
Testing indicates the issue persists for VoiceOver users on iOS after the initial fix. A revised fix is in progress. Forms remain fully usable, and the question text is available by moving backward one step from the answer options.
Aug 7, 12:27 UTC
monitoring
A revised fix has been implemented and all caches have been cleared. The question for each multiple-choice group is now presented as ordinary page text directly before its answer options. We are monitoring the results and verifying the change with screen reader testing on affected devices.
Aug 7, 13:01 UTC
resolved
This incident has been resolved. Screen reader testing on an affected device confirms each question is now announced before its answer options.
Aug 7, 13:08 UTC
July 2026
At locations far enough north that the last prayer of the night falls after midnight, which in the summer months includes much of northern Europe, Iceland, Canada and the northern United States, the Prayer Times page could name the wrong upcoming prayer. Just after midnight the page could point to the following morning's Fajr while a prayer was in fact only minutes away, and in the evening the countdown to the last prayer of the night could announce that its time had arrived early and then stop counting down. Separately, for up to an hour after local midnight the page could still show the previous day's Islamic date. The listed prayer times themselves were correct throughout, visitors at other latitudes were unaffected, and no account data was involved. All three have been corrected and the page has been checked against several northern locations.
Jul 24, 2026
minor
4 updates
investigating
We are currently investigating the next-prayer information shown on the Prayer Times page for locations far to the north, where the last prayer of the night can fall after midnight. This came out of a routine review rather than a visitor report. The listed prayer times themselves are correct.
Jul 24, 23:12 UTC
identified
The issue has been identified and a fix is being implemented. At those locations the page could name the following morning's prayer while a prayer was in fact only minutes away, and the countdown to the last prayer of the night could announce its arrival early and then stop counting down.
Jul 24, 23:18 UTC
monitoring
A fix has been implemented and we are monitoring the results. The next prayer and its countdown now follow the correct prayer at every latitude, and rows are no longer marked as completed before they have passed. If the page still behaves as before, reloading it will pick up the fix.
Jul 24, 23:24 UTC
resolved
This incident has been resolved. A related correction was also applied so the Islamic date turns over promptly at local midnight rather than up to an hour later. The early arrival announcement was possible from July 23; the misnamed next prayer applied to northern locations during the summer months and has been present for longer. Visitors at other latitudes were unaffected and no account data was involved.
Jul 24, 23:32 UTC
With English translation turned on, pausing the Quran player while an English translation was being read and then resuming could skip the remainder of that translation and continue at the next verse in Arabic. Arabic-only listening, seeking, and all other player features were unaffected, and no data was involved. The cause was a recovery check that runs after resuming playback: it could misread healthy translation playback as stalled and restart playback at the following verse. The check now recognizes translation playback correctly, so pausing and resuming during a translation continues exactly where it left off.
Jul 17, 2026
minor
4 updates
investigating
We are currently investigating a report that pausing the Quran player while an English translation was being read and then resuming could skip the rest of that translation and continue at the next verse. Device diagnostics have been captured and are being reviewed.
Jul 17, 15:55 UTC
identified
The issue has been identified. A recovery check that runs after resuming playback could misread translation playback as stalled and restart playback at the following verse. A fix is being implemented.
Jul 17, 15:58 UTC
monitoring
A fix has been implemented and we are monitoring the results. Pausing and resuming during an English translation now continues exactly where it left off. If the issue still appears, reloading the page will pick up the fix.
Jul 17, 16:00 UTC
resolved
This incident has been resolved. The issue could affect listening with English translation turned on since that feature was introduced on July 5. Pausing and resuming during a translation now continues from the same position on all devices.
Jul 17, 16:02 UTC
When the English translation option was turned on for a verse-by-verse reciter, playback could occasionally start in a silent state: the player showed itself as playing, but no audio was heard, and pressing Play again did not recover. Arabic-only listening and all other player features were unaffected, and no data was involved. The cause was a rare condition in the browser's audio engine that left it unable to produce sound while still reporting normal playback. The player now detects this condition within about a second, restarts its audio engine automatically, and resumes from the same position, so listening continues without interruption.
Jul 16, 2026
minor
4 updates
investigating
We are currently investigating a report that turning on English translation in the Quran player could leave it silent: the player appeared to be playing, but no audio was heard, and pressing Play again did not recover. Device diagnostics have been captured and are being reviewed.
Jul 16, 14:58 UTC
identified
The issue has been identified. In a rare condition, the browser's audio engine could enter a state where it reported normal playback while producing no sound. A fix is being implemented.
Jul 16, 15:06 UTC
monitoring
A fix has been implemented and we are monitoring the results. The player now detects the silent condition automatically, restarts its audio engine, and resumes from the same position. If the player still appears stuck, reloading the page will pick up the fix.
Jul 16, 15:09 UTC
resolved
This incident has been resolved. If the silent condition occurs, the player now recovers on its own within about a second and listening continues from the same position.
Jul 16, 15:12 UTC
Some signed-in listeners found that when they used Continue reading to pick up where they left off, the player did not remember the reciter they had been listening to, and playback could start again from the beginning of the surah instead of the saved verse. A separate report described the two-finger control for pausing playback not behaving as expected on some devices. Most listening worked normally and no account data was affected. Both behaviors have been corrected and confirmed: Continue reading now restores the saved reciter and resumes at the saved verse, and the two-finger pause control holds as expected. A Clear option was also added so listeners can empty their Continue reading list at any time.
Jul 16, 2026
minor
5 updates
investigating
We are currently investigating reports that the Quran player did not restore the saved reciter when resuming from the Continue reading list, and that the two-finger pause gesture did not behave as expected on some devices. Recitation itself is playing normally.
Jul 16, 01:47 UTC
update
An initial fix has been deployed for the reciter and resume position. Continue reading now restores the reciter that was in use and resumes at the saved verse instead of the beginning of the surah. We are continuing to investigate the two-finger pause behavior.
Jul 16, 02:00 UTC
identified
The two-finger pause issue has been identified. Device diagnostics showed that a single pause gesture was being registered as two opposing commands at nearly the same instant, which combined to resume playback instead of pausing it. A fix is being implemented.
Jul 16, 02:33 UTC
monitoring
A fix has been deployed and we are monitoring the results. The two-finger pause gesture is now treated as a single action, so pausing after resuming from a saved position holds as expected. If you have the player open, please refresh to pick up the update.
Jul 16, 02:34 UTC
resolved
This incident has been resolved. Continue reading restores the reciter and resumes at the saved verse, and the two-finger pause now holds correctly after resuming. No account data was affected at any point.
Jul 16, 02:36 UTC
between 23:05 UTC on July 11 and 11:46 UTC on July 12, visitors to gablvm.org were shown our maintenance page instead of the website. A routine software update the previous evening did not finish cleanly and left the site in maintenance mode. For much of that window our content delivery network continued to serve saved copies of pages, so many visitors still saw the site normally, but direct visits increasingly reached the maintenance page instead. No data was lost and visitor security was never affected; the site content itself was intact throughout. Maintenance mode has been switched off, cached copies have been refreshed, and the site has been verified healthy. We are also tightening our monitoring so a stuck maintenance page is caught much sooner in the future.
Jul 11, 2026
to Jul 12, 2026
major
5 updates
investigating
We are currently investigating an alert from our automated monitoring that the website is returning an error response instead of loading normally.
Jul 12, 09:05 UTC
identified
The issue has been identified and a fix is being implemented. The site was left in maintenance mode after a routine software update the previous evening did not complete cleanly, so visitors were shown the maintenance page rather than the website itself.
Jul 12, 11:43 UTC
monitoring
A fix has been implemented and we are monitoring the results. Maintenance mode has been switched off and cached copies of pages have been refreshed. If the maintenance page still appears, reloading the page should bring the site back.
Jul 12, 11:46 UTC
resolved
This incident has been resolved. The website is confirmed to be loading normally. Direct visits could reach the maintenance page between 23:05 UTC on July 11 and 11:46 UTC on July 12; cached copies served by our content delivery network meant many visitors were unaffected for much of that window. No data was affected.
Jul 12, 11:49 UTC
update
A full post-incident analysis of this outage, covering the timeline, the root cause, the ten-hour detection gap, and the monitoring and tooling changes already in place, has been published at https://gablvm.org/articles/2026/07/twelve-hours-down-full-story-july-11-outage
Jul 12, 12:10 UTC
Shortly after the new country and region menus were released on the Prayer Times page, choosing a country, or a country and a region, without typing a city worked for that visit but was not remembered: the next visit fell back to the default location. The location label could also show a stray leading comma when no city was chosen, which screen readers read aloud. Prayer times themselves were always calculated correctly for the chosen place, and no personal data was involved. Both issues were fixed and verified the same afternoon, about half an hour after the release.
Jul 7, 2026
minor
4 updates
investigating
While answering a visitor question about how the Prayer Times page remembers a chosen location, we are reviewing the location settings released earlier this afternoon. Prayer times are calculating correctly; we are checking how choices are saved between visits.
Jul 7, 14:39 UTC
identified
Two issues have been identified and a fix is being implemented. A country or region chosen without a city was not being remembered for the next visit, and the location label could show a stray leading comma when no city was set. Times themselves were unaffected.
Jul 7, 14:44 UTC
monitoring
A fix has been deployed and we are monitoring the results. Country-only and region-only choices are now remembered between visits, and the location label reads cleanly. If you have the page open, please refresh to pick up the update.
Jul 7, 14:48 UTC
resolved
This incident has been resolved. A choice of country, or country and region, made between 14:20 and 14:51 UTC today may not have been remembered; choosing it once more will now stick. Everything was verified end to end, and no personal data was involved.
Jul 7, 14:54 UTC
For a period after the after-each-verse English translation was extended to more reciters in the Quran player, the spoken English translation did not play for a small number of reciters, even though the option appeared available for them. Arabic recitation played normally throughout. A listener reported it. The cause was identified and corrected, and the English translation now plays for these reciters as well. Other reciters were unaffected and no personal data was involved.
Jul 6, 2026
minor
4 updates
investigating
We are investigating reports that the spoken English translation did not play for a small number of reciters in the Quran player, even though the option appeared available for them. Arabic recitation and all other reciters are working normally.
Jul 6, 13:20 UTC
identified
The issue has been identified and a fix is being implemented. It affects only the optional after-each-verse English translation for a few specific reciters; Arabic recitation plays normally for every reciter.
Jul 6, 13:44 UTC
monitoring
A fix has been deployed and we are monitoring the results. The English translation now plays for the affected reciters. If you have the page open, please refresh to pick up the update.
Jul 6, 13:48 UTC
resolved
This incident has been resolved. The English translation is confirmed playing correctly for the affected reciters, and other reciters were unaffected throughout. No personal data was involved.
Jul 6, 13:55 UTC
Navigation links intended for site staff were visible to all visitors on the Contact page. The links did not expose any information: the pages behind them remained protected throughout and no form submissions or personal data were accessible. The issue has been resolved and the links no longer appear.
Jul 4, 2026
minor
4 updates
investigating
We are currently investigating a finding from a routine site review that navigation links intended for site staff were visible to visitors on the Contact page. The contact form itself is working normally for all visitors.
Jul 4, 05:31 UTC
identified
The issue has been identified and a fix is being implemented. The cause was a site permissions configuration issue. The pages behind the links remained protected throughout, and no form submissions or personal data were accessible at any point.
Jul 4, 05:40 UTC
monitoring
A fix has been implemented and we are monitoring the results. The staff-only links no longer appear on the Contact page. If the links are still visible, please refresh the page.
Jul 4, 05:52 UTC
resolved
This incident has been resolved. The Contact page is confirmed to display correctly for visitors, and an independent verification confirmed that no information was exposed at any point. No data was impacted.
Jul 4, 05:55 UTC
On the Quran Player page, several controls stopped responding: enabling English translation did not add the translation audio, playback no longer continued automatically to the next surah when that option was selected, and the previous and next surah buttons did not respond. Reciter selection and standard Arabic recitation continued to work normally, and no personal data was affected. The issue has been resolved and the affected controls now respond as expected.
Jul 3, 2026
minor
4 updates
investigating
We are currently investigating reports that some controls on the Quran Player page are not responding, including the English translation option and the previous and next surah buttons. Reciter selection and standard playback are working normally.
Jul 3, 22:36 UTC
identified
The issue has been identified and a fix is being implemented. A recent update to the player caused several of its controls not to activate; the recitation audio itself was unaffected.
Jul 3, 22:50 UTC
monitoring
A fix has been implemented and we are monitoring the results. The player has been updated and its cached files cleared. If you still see an unresponsive control, please refresh the page.
Jul 3, 23:02 UTC
resolved
This incident has been resolved. Enabling English translation, automatic advance to the next surah, and the previous and next surah buttons are confirmed to be working again. The controls were affected on July 3; recitation playback continued to work throughout and no data was impacted.
Jul 3, 23:06 UTC
The Prayer Times page remembers a visitor's location between visits, and an issue in how that location was stored meant it could continue showing a location the visitor had since left. Prayer times were always calculated correctly for the location shown and no data was affected, and most visitors were unaffected. The issue has been resolved and the location handling redesigned so a saved location now updates when a visitor moves.
Jul 3, 2026
minor
4 updates
investigating
We are currently investigating reports that the Prayer Times page was continuing to show a previously saved location instead of the visitor's current one. Prayer times for the location shown remained accurate.
Jul 3, 06:44 UTC
identified
The issue has been identified and a fix is being implemented. The cause was in how the page stored a saved location: a manually entered location was not retained between visits, and a saved location was not re-checked when the visitor moved.
Jul 3, 07:05 UTC
monitoring
A fix has been implemented and we are monitoring the results. A manually entered location is now retained between visits, and the page re-checks a saved location and updates it when the visitor has moved. If the page still shows an outdated location, please refresh, or set it again using the Use My Location button or the city field.
Jul 3, 07:25 UTC
resolved
This incident has been resolved. The Prayer Times page is confirmed to update a saved location correctly across return visits. Impact was limited to the location shown on July 3 and prayer times themselves remained accurate; no data was impacted. A safeguard is in place so a saved location now refreshes when a visitor moves.
Jul 3, 07:30 UTC
On July 1 we upgraded gablvm.org to Drupal 11.4, the newest release of the platform the website runs on. During the upgrade the site was briefly unavailable: for roughly twelve minutes visitors saw an error page and then a maintenance page instead of the site. Two upgrade steps did not complete in the expected order, which we identified and finished within minutes; the site was then restored, every tool was verified working, and the upgrade completed successfully. No data was affected, and nothing changes in how the site or its tools work. The new platform release makes pages faster for the server to build, which keeps the site quick as it grows.
Jul 1, 2026
major
4 updates
investigating
During a planned upgrade of the website to the newest platform release, the site has begun returning an error page instead of loading normally. We are investigating immediately. No data is at risk; this is an upgrade in progress rather than a failure of the site itself.
Jul 1, 22:11 UTC
identified
The cause has been identified. Two steps of the platform upgrade did not complete in the expected order, which left the site unable to start. We are completing the remaining steps now, and the site is in maintenance mode while the final updates run.
Jul 1, 22:19 UTC
monitoring
The upgrade has completed and the site is back online. Every page and tool, including prayer times, the Quran player, the Hijri calendar, and qibla, is loading normally, and caches have been refreshed so visitors get the new version. We are monitoring while we run our full checks.
Jul 1, 22:22 UTC
resolved
This incident has been resolved. The website is running on the new platform release, every tool has been verified working, and our automated test suite passes in full. Total impact was roughly twelve minutes on July 1, from 22:10 to 22:22 UTC, during which the site showed an error page and then a maintenance page. No data was affected, and nothing changes in how you use the site.
Jul 1, 22:27 UTC
For a period, the Quran player's playback-speed control did not respond when it was changed while audio was playing, on all devices; the chosen speed only took effect after pausing and resuming or moving to the next chapter. Setting the speed before starting playback worked normally, and no data was affected. A listener reported it. Initial improvements to speed handling did not resolve it, and a deeper investigation found the underlying cause: the speed control was not being connected to the player when the page loaded, so changing it had no effect. That has been corrected and confirmed working.
Jul 1, 2026
minor
5 updates
investigating
We are currently investigating a report that the Quran player's playback-speed control does not respond when it is changed while audio is playing. Setting the speed before starting playback works normally, and the rest of the player is unaffected.
Jul 1, 09:20 UTC
update
We have deployed initial improvements to how playback speed is handled, but the control still does not reliably take effect when it is changed during playback, so our investigation is continuing.
Jul 1, 09:40 UTC
identified
The issue has been identified. The cause was in the page itself: the speed control was not being connected to the player when the page loaded, so changing it had no effect until an unrelated action re-read the value. This affected the control on all devices. The recitation audio was unaffected. A corrected fix is being implemented.
Jul 1, 10:05 UTC
monitoring
A fix has been implemented and we are monitoring the results. The speed control now responds immediately when it is changed during playback, on all devices. We are confirming the fix before closing this out. If you still see the older behavior, reload the page once.
Jul 1, 10:12 UTC
resolved
This incident has been resolved and the fix confirmed working. The playback-speed control now responds immediately whenever it is changed, during playback and across devices, and keeps your chosen speed from one chapter to the next. Impact was limited to the speed control; the player was otherwise working throughout and no data was affected. If you still notice the older behavior, reload the page once to clear your cache.
Jul 1, 10:18 UTC
For a period, with the English audio translation turned on, the Quran player's Mute button and the keyboard speed shortcuts did not take effect, and turning the translation on at the very start of a chapter could move playback to the wrong verse. The recitation itself kept playing and no data was affected. These were found in a routine review of the player rather than reported, and each was fixed; mute and the speed controls now work with the translation on, and enabling it at the start of a chapter keeps your place. If you still see the older behavior, reload the page once.
Jul 1, 2026
minor
4 updates
investigating
We are looking into a set of issues in the Quran player that appear when the English audio translation is turned on: the Mute button and the keyboard speed shortcuts may not take effect, and turning the translation on at the very start of a chapter can move playback to the wrong verse. This surfaced in a routine review rather than a report, and the recitation itself is playing normally.
Jul 1, 06:04 UTC
identified
The cause has been identified and a fix is being prepared. It is in how the player handles these controls while the English translation is active on the client side; the recitation audio and your data are unaffected.
Jul 1, 06:12 UTC
monitoring
A fix has been deployed and the page cache cleared, and we are monitoring the result. With the English translation on, mute and the speed shortcuts now take effect, and turning the translation on at the start of a chapter keeps your place. If you still see the older behavior, reload the page once.
Jul 1, 06:19 UTC
resolved
This incident has been resolved. With the English translation on, the Mute button and the keyboard speed controls now work as expected, and enabling the translation at the start of a chapter keeps your place. The recitation played normally throughout and no data was affected. If you still notice the older behavior, reload the page once to clear your cache.
Jul 1, 06:21 UTC
June 2026
Some visitors saw an incorrect next prayer on the Prayer Times page, or a stale date on the Islamic Calendar, with different devices showing different values for the same location. The cause was a caching issue: these time-sensitive values were calculated when the page was generated and then cached, so they could freeze and be served out of date. Both pages now keep these values current on every visit.
Jun 25, 2026
major
4 updates
investigating
We are investigating reports that the Prayer Times page can show the wrong next prayer on some devices. A community member reported two devices at the same location displaying a different next prayer.
Jun 25, 03:28 UTC
identified
We have identified the cause. The next prayer and its countdown were calculated when the page was generated and then cached at our content delivery network and in the browser, so the value could freeze at the moment a cached copy was created and be served out of date. The Islamic Calendar's current date and today highlight were affected by the same issue. A fix is being implemented.
Jun 25, 03:33 UTC
monitoring
A fix has been deployed. The Prayer Times page now calculates the next prayer and countdown live in your browser on every visit, so it is always current regardless of caching. The Islamic Calendar is no longer served from the edge cache, so its date and today highlight stay current. We are monitoring to confirm.
Jun 25, 03:50 UTC
resolved
This incident is resolved. The next prayer now updates live on every device and the Islamic Calendar shows the correct current date. We also corrected a related issue where the spoken Tomorrow note on the prayer countdown was not announced. Thank you to the community member who reported this.
Jun 25, 03:56 UTC
When using the Quran player, turning the English translation audio on or off during playback could move the position forward, sometimes skipping a verse, instead of continuing from the same place. This was limited to the English-translation toggle on verse-by-verse reciters; ordinary Quran playback was unaffected and no audio was ever wrong. The issue has been fixed and verified on the live player.
Jun 22, 2026
minor
4 updates
investigating
We are investigating a report that the Quran player can jump forward, or skip a verse, when the English translation audio is switched on or off during playback. Listening to the Quran without toggling the translation is not affected.
Jun 22, 02:30 UTC
identified
The cause has been identified: a client-side issue in how the player handed off your current position when switching between its Arabic-only and English-translation playback modes. The audio itself was always correct; only the resume position was off. A fix is being prepared.
Jun 22, 02:37 UTC
monitoring
A fix has been deployed and the page cache cleared. We are monitoring the result. If you still see the player jump when toggling English, please reload the Quran player page once to pick up the update.
Jun 22, 03:05 UTC
resolved
This incident is resolved. Toggling the English translation now keeps your place: turning it on resumes the same verse, and turning it off continues at the next verse. This was verified on the live player. No data was affected, and exposure was limited to the English-translation toggle on verse-by-verse reciters.
Jun 22, 03:12 UTC
During a routine review of the Quran tools we identified and corrected a few minor issues. The audio reader could fail to show an error message when speech could not start on a device, and a linked Quran.com account could remain shown as connected after its link had expired. These were edge cases affecting a small number of situations; the tools remained available throughout, and no data was affected. All items have been fixed and verified.
Jun 20, 2026
to Jun 21, 2026
minor
4 updates
investigating
We are reviewing the Quran player and account tools after an internal audit surfaced a few minor items to look into. The tools are available and working normally; this is a precautionary review.
Jun 20, 21:30 UTC
identified
The items have been identified. They include the article audio reader not always showing a clear message when speech cannot start on a device, a linked Quran.com account occasionally remaining shown as connected after its link has expired, and a few smaller reliability improvements. The underlying tools were healthy throughout; these are edge cases.
Jun 20, 22:45 UTC
monitoring
Fixes have been implemented and we are monitoring them. The audio reader now reports clearly when it cannot start so it never appears to be reading in silence; an expired account link now prompts you to reconnect instead of appearing connected; and the additional reliability improvements are in place. Our automated test suite passes.
Jun 21, 00:20 UTC
resolved
This incident is resolved. All identified items are fixed and verified by our automated tests. Impact was limited to minor edge cases for a small number of users, with no downtime and no effect on any data.
Jun 21, 00:55 UTC
On iPhone, switching headphones during Quran playback could briefly interrupt the audio while the device reconfigured its audio output. The recitation always recovered on its own and no audio or saved data was lost, but because it affected a core feature we treated it as a genuine playback-quality issue. After investigation we identified the cause in how iOS handles audio route changes and resolved it by changing how Arabic recitation is delivered so the device manages the transition natively. A brief, self-recovering transition now remains only in the English translation mode.
Jun 18, 2026
minor
4 updates
investigating
We are investigating reports that, on iPhone, switching headphones during Quran playback can briefly interrupt the audio. The recitation continues and no audio or saved data is lost; the effect occurs only at the moment headphones are connected or disconnected.
Jun 18, 17:55 UTC
identified
We have identified the cause. When headphones are connected or disconnected, iPhone reconfigures its audio hardware, and during that brief reconfiguration the player's audio engine is interrupted before it resumes. This is an inherent characteristic of how the platform handles audio route changes rather than a fault in the recitation itself. We are implementing a fix that changes how the audio is delivered so the device manages the transition smoothly.
Jun 18, 19:30 UTC
monitoring
A fix has been implemented and we are monitoring it. For the most common case, listening to a reciter in Arabic, the player now delivers the recitation in a form the device handles natively, so connecting or disconnecting headphones no longer interrupts playback. We are confirming the improvement across devices.
Jun 18, 20:45 UTC
resolved
This incident is resolved. Switching headphones during Arabic recitation is now smooth, with no interruption. A brief, self-recovering pause can still occur in the English translation mode, which is an inherent platform behavior during an audio route change; it does not lose your place and clears on its own. Throughout, impact was limited to a momentary audio interruption at the instant of a headphone change, with no downtime and no data affected.
Jun 18, 21:35 UTC
During an internal accessibility and reliability review, we found and fixed several minor issues across a few of our tools, most of them affecting screen-reader users in specific situations. The tools kept working normally throughout and no data was affected, and most visitors saw no difference. The issues have been resolved.
Jun 16, 2026
to Jun 17, 2026
minor
4 updates
investigating
We are carrying out an internal accessibility and reliability review of several of our tools, including the prayer times, the Islamic calendar, the qibla finder, and the reading-aloud feature. The tools are working normally for visitors throughout.
Jun 16, 23:30 UTC
identified
The issues have been identified and fixes are being implemented. They mostly affect screen-reader users in specific situations, for example a date shown with its underlying formatting after the day's last prayer, focus not returning to the right place after certain actions, and the reading-aloud control not always restarting audio after a pause. No data is affected.
Jun 17, 00:05 UTC
monitoring
Fixes have been implemented and we are monitoring the results. The Hijri date now displays correctly, focus returns where expected for screen-reader users, the reading-aloud feature resumes reliably, and the qibla finder shows a fixed direction on devices that cannot provide a true bearing. If you had a page open, please reload it once to pick up the update.
Jun 17, 00:50 UTC
resolved
This incident has been resolved. All of the identified issues are fixed and live. Impact was minor and limited to the behavior of these tools in specific situations; the tools kept working throughout, most visitors were unaffected, and no data was impacted.
Jun 17, 01:25 UTC
For a period, the Quran player could play the English audio translation out of step with the recited verse, pause briefly between verses, lose your place when seeking, and stop playing when the device was locked, in the background, or after a headphone change. Most listening worked normally throughout and no data was affected. These came up while we rebuilt the player on a new audio engine, and each one was identified and fixed; the player now plays seamlessly, keeps the translation in sync, seeks reliably including while paused, and continues in the background. This was a major rebuild of the site's flagship feature, and the work is complete.
Jun 15, 2026
to Jun 16, 2026
major
4 updates
investigating
We are currently investigating reports about the Quran player: with the English audio translation on, the recitation could land on a different verse than the one being read, and the audio could pause briefly between verses for some reciters. Most listening is working normally.
Jun 15, 20:23 UTC
identified
The issue has been identified and a fix is being implemented. The cause was in how the player handled the separate per-verse audio files and the English translation on the client side; the recitation audio itself was unaffected. We are rebuilding the player's audio engine to resolve it properly.
Jun 15, 21:09 UTC
monitoring
A fix has been implemented and we are monitoring the results. The Quran player's audio engine has been rebuilt and rolled out for the supported reciters: the recitation now plays seamlessly from one verse to the next, the English translation stays matched to each verse, and seeking is in minutes and seconds. We are continuing to validate seeking, background and lock-screen playback, and the headphone and VoiceOver controls. If you still see older behavior, reload the page once.
Jun 15, 23:52 UTC
resolved
This incident has been resolved. The Quran player is rebuilt and confirmed working for everyone: it plays seamlessly verse to verse, the English translation stays in sync and keeps your place when toggled, seeking works forward and back including while paused and with VoiceOver, and playback continues when the device is locked, in the background, or after headphones are plugged in or out. Impact was intermittent and limited to the player's audio behavior; no data was affected. If you still notice older behavior, reload the page once to clear your cache.
Jun 16, 18:30 UTC
The website homepage intermittently returned an error response to some requests due to an issue in our caching layer. The underlying site remained healthy throughout and most visitors were unaffected. The issue has been resolved and a safeguard added to prevent recurrence.
Jun 2, 2026
minor
4 updates
investigating
We are currently investigating reports that the website homepage was intermittently returning an error response to some requests. Most visitors are able to load the site normally.
Jun 2, 18:12 UTC
identified
The issue has been identified and a fix is being implemented. The cause was an error response being served by our caching layer; the underlying website remained healthy throughout.
Jun 2, 19:50 UTC
monitoring
A fix has been implemented and we are monitoring the results. The affected cached response was cleared and a safeguard was added so error responses are no longer cached. If you saw an error earlier, please refresh and the page will load normally.
Jun 2, 19:56 UTC
resolved
This incident has been resolved. The homepage is confirmed to be responding normally. Impact was intermittent and primarily affected automated requests on June 2; most visitors were unaffected. No data was impacted and a safeguard is in place to prevent recurrence.
Jun 2, 20:05 UTC
April 2026
On 23 April 2026, screen reader users on iOS Safari reported that the location permission prompt on the Prayer Times page was not completing successfully. Investigation identified three browser-compatibility issues with iOS Safari's Permissions and Dialog APIs, each one masking the next. All three were resolved in releases 2.0.2, 2.0.3, and 2.0.4 of the gablvm_core module, with additional UX and accessibility refinements shipping through release 2.0.8. A subsequent user report was traced to an iOS Safari Website Setting that silently grants location access without showing a system prompt; in that case the application was functioning as designed, but the outcome was not visible to the user. Users who wish to restore the native iOS Safari prompt can change their Safari Website Settings for gablvm.org from 'Allow' to 'Ask'. The application's in-app acceptance flag can be reset at any time by visiting /prayer-times?resetLocation=1. All fixes are live on both origin servers.
Apr 23, 2026
minor
4 updates
investigating
Reports received that screen reader users on iOS Safari are unable to complete the location permission flow on the Prayer Times page. The dialog either does not appear, or selecting Continue does not trigger the native permission prompt. Engineering is investigating.
Apr 23, 02:20 UTC
identified
Root cause identified for the first reported symptom. A change in iOS Safari's handling of the Permissions API caused the geolocation request to run outside the required user-gesture context, which prevented the native prompt from appearing. A fix has been released as gablvm_core 2.0.2.
Apr 23, 02:48 UTC
monitoring
Two additional iOS Safari compatibility issues were uncovered during regression testing and have been resolved: a user-gesture lifecycle issue affecting the Continue button (2.0.3), and a fallback path that bailed prematurely under Safari private browsing (2.0.4). Further UX and accessibility refinements shipped in releases 2.0.5 through 2.0.8. All fixes are deployed to both origin servers. Monitoring for additional reports.
Apr 23, 04:17 UTC
resolved
Incident resolved. A subsequent user report was traced to an iOS Safari Website Setting that grants location access silently without a system prompt. In that case the application was behaving correctly, but the outcome was not visible to the user. Users wishing to restore the native iOS Safari prompt can change their Safari Website Settings for gablvm.org from 'Allow' to 'Ask'. The application's in-app acceptance flag can also be reset by visiting /prayer-times?resetLocation=1.
Apr 23, 05:30 UTC
At 00:00:01 UTC on 2026-04-20, the external status-page probe detected that status.gablvm.org returned a 200 response that did not contain the expected v3 template marker. The response cleared on the next probe cycle 10 minutes later with no intervention. No deploy happened in that window (the live Cloudflare Worker version did not change). Investigation identified the most likely cause as a transient Cloudflare edge bot-fight challenge triggered by the probe's fixed-IP 10-minute pattern. Mitigation applied: probe now sends an identifiable User-Agent and the server IP is whitelisted in Cloudflare's firewall. Site was never unreachable to real users during this window.
Apr 20, 2026
minor
4 updates
investigating
Tier 2 external probe detected that status.gablvm.org returned a 200 response missing the expected v3 template marker at 00:00:01 UTC. No code deploy happened in that window. Investigating whether this is a stale-bundle recurrence or an edge-level event.
Apr 20, 00:00 UTC
identified
Correlated the probe log with the Cloudflare Worker version history. The live Worker version did not change during the incident window. The response cleared on the very next 10-minute probe cycle with zero intervention, so this was not a deploy drift. Most likely cause is a transient Cloudflare edge event — the probe's fixed-IP 10-minute pattern can trip bot-fight heuristics briefly.
Apr 20, 00:15 UTC
monitoring
Two mitigations deployed: (1) the external probe now sends an identifiable User-Agent header, (2) the source server's IP address is added to Cloudflare's zone allowlist. Running 8 back-to-back manual probes confirmed the marker is present on every response. Monitoring the next few probe cycles for stability.
Apr 20, 00:30 UTC
resolved
All automated probes have reported healthy since the mitigations were applied. Public users were never affected — the only impact was a false-positive internal alert. The status page has been operating normally throughout.
Apr 20, 00:35 UTC
The status page briefly displayed 0% uptime for the Support Portal and Status Page services themselves, while both services were actually operational. This was a display regression caused by an older version of the status page template remaining active on the edge. No actual service was affected, and no data was lost. Only the displayed uptime percentages for those two services were incorrect. The fix restored the correct display behavior, which excludes services whose uptime is manually tracked rather than automatically monitored.
Apr 19, 2026
minor
4 updates
investigating
A user report indicated that the status page was displaying 0% uptime for the Support Portal and Status Page listings, while both services were responding normally and all other services showed expected uptime percentages. We are investigating the display discrepancy.
Apr 19, 21:40 UTC
identified
Root cause identified. The deployed version of the status page template was older than the current source and did not correctly handle services whose uptime is manually tracked rather than automatically monitored. Those services (Support Portal and Status Page themselves, which cannot meaningfully monitor their own platform) were being rendered as 0% instead of being excluded from the uptime chart. A corrected template already exists in source; the fix is to redeploy the current build.
Apr 19, 21:50 UTC
monitoring
A fix has been deployed to production. The updated template correctly filters services that are not automatically tracked from the uptime display, eliminating the misleading 0% indicator. We are monitoring the live status page for the corrected rendering.
Apr 19, 22:00 UTC
resolved
Fix verified in production. The status page now renders only automatically tracked services in the uptime chart, and the Support Portal and Status Page entries no longer display a misleading 0% value. Issue first reported on 2026-04-19 and resolved the same day. No underlying service was affected during the incident.
Apr 19, 22:05 UTC
A client-side bug could cause the Quran Player's seek bar and skip buttons to stop responding if the audio stream was interrupted mid-playback and the recovery path encountered a network error. Users experiencing this could recover by reloading the page. The issue has been identified and resolved. The player now preserves playback state across network interruptions so the controls remain responsive, and a clear retry message is shown if audio fails to load. No data loss, no security impact.
Apr 17, 2026
minor
4 updates
investigating
A user-reported issue: the Quran Player stopped responding in the middle of a surah. Seek bar and skip controls are unresponsive. Reloading the page restores normal operation. We are Investigating the issue.
Apr 17, 10:30 UTC
identified
Root cause identified. A client-side state-handling issue causes the player to become unrecoverable if the automatic recovery path encounters a network error after an upstream audio stream stalls. We are working on a fix for this issue.
Apr 17, 10:40 UTC
monitoring
A fix has been deployed to production and server cache is purged. We are monitoring the Quran Player for residual issues. Existing browser sessions should reload the page to pick up the fix.
Apr 17, 10:50 UTC
resolved
Fix deployed to production. The Quran Player now preserves playback state across network interruptions so the seek bar and skip buttons remain responsive, and a clear retry message is shown when audio fails to load. Latent bug introduced on or before 2026-03-13, detected and resolved on 2026-04-17.
Apr 17, 11:00 UTC
Two unrelated fixes shipped together in this update. First, the Support Portal and Status Page services were incorrectly showing 0% uptime over the last 90 days because an older version of the monitoring worker was writing health check records for services that are managed manually. A fix for this exact issue was made yesterday but the deployment bundle was stale and did not include the correction. The monitoring worker has now been redeployed with the correct code, the inaccurate records have been cleaned up, and the 90 day uptime display has been restored to an accurate value. Second, on small mobile viewports the cookie consent banner could take up more than 80 percent of the screen and cover form fields on the Contact Us and Newsletter pages of gablvm.org, which made it difficult for mobile visitors to reach the full form before accepting or declining cookies. The banner has been redesigned to be compact on mobile, its height is now capped, and content above it is automatically adjusted so every form field remains reachable. The site footer has also been reorganized on tablet and desktop into a two column layout, reducing its overall height by roughly 20 percent on short content pages. No data or functionality was affected by either fix.
Apr 12, 2026
maintenance
The main website and API were unreachable for approximately 43 minutes this morning due to a fault affecting the origin server. Service was restored after a restart, and a permanent fix has since been applied at the infrastructure layer to prevent the issue from recurring.
Apr 11, 2026
major
6 updates
investigating
We are investigating reports that gablvm.org is returning errors for visitors.
Apr 11, 04:16 UTC
identified
The origin server is currently unreachable, and Cloudflare is returning 523 errors for all requests to the main site and API. We are working to restore service as quickly as possible.
Apr 11, 04:17 UTC
monitoring
Service has been restored. The main website and API are responding normally. We are continuing to monitor for stability.
Apr 11, 04:59 UTC
update
A brief performance degradation occurred shortly after recovery and resolved automatically within about 40 seconds. The site remained reachable throughout and no further impact is expected.
Apr 11, 05:05 UTC
update
A short-term protective measure has been applied while a permanent fix is prepared at the infrastructure layer. Service remains stable.
Apr 11, 06:15 UTC
resolved
A permanent fix has been applied at the infrastructure layer and the underlying cause can no longer recur. All services are healthy. Total downtime: approximately 43 minutes. We appreciate your patience.
Apr 11, 06:36 UTC
Complete visual redesign of gablvm.org inspired by the tradition of illuminated Islamic manuscripts, delivered as release v2.0.1. The site moved from a stock Olivero template look to a warm ivory background with deep forest green and antique gold accents, Fraunces serif headings throughout, and an editorial layout style across every public page. The release was shipped in four phases on 2026-04-10: initial design deployment, polish sweep to fix issues found during the page-by-page review, screen reader accessibility fixes after VoiceOver testing surfaced duplicate-announcement bugs from CSS pseudo-element content, and a desktop layout fix after testing on wide viewports revealed an empty social bar region stealing 90 pixels of space. Throughout the release the site maintained its zero WCAG 2.2 AA violation record, and every change was verified against AAA contrast thresholds before shipping. The eu-cookie-compliance banner was also restyled to match the new aesthetic. No user-facing downtime during the change.
Apr 10, 2026
maintenance
5 updates
in_progress
Phase 1: Visual redesign deployment. Background shifts from white to warm ivory. Fraunces serif loaded alongside Inter for all headings site-wide, with Inter kept for body text because it is the most accessible sans-serif for low vision users. Homepage rebuilt as alternating full-bleed bands: deep green hero with bismillah gold eyebrow, numbered editorial What We Do section with Roman numeral entries, parchment Faith section, Accessible Tools list, and a closing Dua band. Blog listing converted to a two column editorial grid with gold hairlines. Article detail pages get a magazine style reading layout with a gold drop cap on the first paragraph. The Quran Player, Prayer Times, Islamic Calendar, and Qibla Finder pages all restyled with a unified ivory surface, deep green top border with a gold hairline, and serif headings. Footer rebuilt as a deep green closing band with gold hairlines and a star ornament. Initial deployment complete.
Apr 10, 18:30 UTC
in_progress
Phase 2: Polish sweep across every public page. Found and fixed five issues: the magazine drop cap was leaking onto blog teaser cards in the listing view, the Events page table was still using the old dark green styling from the previous module CSS, the Resources list was also still using the old dark green card treatment, the About and Programs and Services pages were rendering duplicate titles because their node bodies contained their own hero sections with h2 tags matching the page title block above, and the Drupal CSS aggregator was serving stale aggregates that did not include the latest edits. Resolved the stale aggregate issue by bumping the theme library version to force filename regeneration. All five issues fixed. Every page now renders cleanly on desktop.
Apr 10, 20:00 UTC
in_progress
Phase 3: Screen reader accessibility fixes. During VoiceOver testing in linear swipe mode, a blind user reported that small caps eyebrow labels (our mission, what we do, faith, tools) were being announced twice, because they were implemented as CSS pseudo element content on the same h2 elements as the real headings. VoiceOver headings rotor navigation hid the duplication, but linear reading order exposed it. The eight point star glyphs used as section dividers were also being announced as "black four pointed star" in the middle of content flow, and the Roman numerals on the purpose cards were being announced before each card title. Fixed by applying the CSS Generated Content alternative text syntax content value slash empty string to every decorative pseudo element, which silences them in the accessibility tree while keeping them visible to sighted users. The full bismillah text (In the name of Allah, the Most Gracious, the Most Merciful) was also added and left readable because it is meaningful content, not decoration. The CSS eyebrow rules were additionally scoped to homepage only so they do not show mismatched labels above unrelated headings on the About and Programs and Services pages. Every decorative pseudo element on the site now skips screen readers.
Apr 10, 21:30 UTC
in_progress
Phase 4: Desktop layout fixes. A user reported that the desktop view at wide viewport widths looked broken, with the cookie banner rendering as a narrow vertical strip and the page content squished into the left half of the screen. Investigation revealed three stacked bugs. First, Olivero ships its page wrapper element with a max width of 1570 pixels but no auto margin, which left aligned the whole site on viewports wider than 1570 pixels. Second, an empty aside element for a disabled social media region was still being rendered as a flex sibling of the main content, stealing 90 pixels of width on the left and pushing the content off center. Third, the cookie compliance popup did not have explicit pinning to the viewport edges, so on wide screens it inherited a 600 pixel width constraint from the Drupal module default and rendered as a narrow box. All three fixed by overriding the page wrapper to full width, hiding the empty social bar aside, and explicitly pinning the cookie banner to the full viewport width. Verified with precise measurements at 1920 by 1080: main content centered at x 420 width 1080 with equal 420 pixel gaps, hero section and cookie banner both at x 0 width 1920.
Apr 10, 22:00 UTC
completed
Release complete. Verified every public page on both desktop at 1920 and 1440 and mobile at 375 pixels wide. All ten key surfaces (homepage, blog listing, blog article, Quran Player, Prayer Times, Islamic Calendar, Qibla Finder, Events, Resources, About, Programs and Services) render cleanly at every viewport. No content overflow, no layout shifts, no duplicate headings, no mismatched eyebrow labels, no broken tables on mobile. Fraunces and Inter both loading correctly. Gold accents and star ornaments consistent across every page. Dark green footer with gold hairlines on every page. Zero WCAG 2.2 AA regressions. Focus rings replaced with bright gold with ivory halos visible on every background. Current prayer and today date use both color and star glyph (never color alone). All motion disabled under prefers reduced motion. Caches purged at Drupal and Cloudflare. Details in the changelog under v2.0.1.
Apr 10, 22:30 UTC
The status page displayed 0% uptime for the Support Portal and Status Page services. All services were operating normally throughout this period. The issue was caused by the health monitoring system incorrectly recording health check results for manually-managed services, which do not require automated health checks. This resulted in inaccurate uptime data being displayed to visitors. The monitoring system has been corrected and the erroneous data has been removed.
Apr 4, 2026
to Apr 5, 2026
minor
4 updates
investigating
We are aware that the status page is displaying 0% uptime for the Support Portal and Status Page services. Both services are operating normally. We are investigating the cause of the incorrect uptime data.
Apr 5, 20:45 UTC
identified
The root cause has been identified. The health monitoring system was incorrectly recording automated health check results for manually-managed services. These services do not require automated health checks, but the monitoring system was checking their URLs and recording every result as a failure, which produced inaccurate uptime percentages.
Apr 5, 21:00 UTC
monitoring
The monitoring system has been updated to exclude manually-managed services from automated uptime recording. 1,276 erroneous health check entries have been removed from the database. Uptime now correctly displays 100% for both affected services. We are monitoring to confirm the fix holds.
Apr 5, 21:10 UTC
resolved
This incident is resolved. The status page now displays accurate uptime data for all services. No actual service disruption occurred during this period. The issue was limited to incorrect data display on the status page.
Apr 5, 21:15 UTC
The prayer times page displayed Shawwal 12 instead of the correct Shawwal 13 due to a stale 24-hour API cache. This could have impacted users planning to observe the white days of fasting (Ayyam al-Beed: 13th, 14th, 15th of each lunar month). The root cause was the API proxy caching prayer data for 24 hours, which meant date transitions were delayed. The cache TTL has been reduced to 1 hour to prevent recurrence.
Apr 1, 2026
minor
4 updates
investigating
We received a report that the prayer times page is displaying Shawwal 12 instead of Shawwal 13. The Hijri calendar page correctly shows the 13th. Our team is investigating the discrepancy between the two pages.
Apr 1, 10:30 UTC
identified
Root cause identified. The API proxy worker at api.gablvm.org was caching prayer timings responses for 24 hours. A request made on March 31 (Shawwal 12) was still being served on April 1 (Shawwal 13) due to the stale cache. This affected any user viewing the prayer times page during this window.
Apr 1, 10:35 UTC
monitoring
Fix deployed. The API worker cache TTL for prayer timings has been reduced from 24 hours to 1 hour. All stale cache entries have been purged from both the Cloudflare edge cache and the Drupal application cache. The prayer times page now correctly displays Shawwal 13, 1447 AH. Monitoring to confirm the fix holds across all regions.
Apr 1, 10:40 UTC
resolved
Confirmed resolved. The prayer times page is displaying the correct Hijri date across all tested locations. The reduced cache TTL will prevent this issue from recurring at future date boundaries. We apologize for any inconvenience, particularly for users relying on the Hijri date for time-sensitive worship such as the white days of fasting (Ayyam al-Beed).
Apr 1, 10:43 UTC
March 2026
All GABLVM services experienced an unplanned disruption due to a hosting infrastructure issue. The root cause has been identified and resolved.
Mar 29, 2026
to Mar 30, 2026
major
5 updates
investigating
All services became unresponsive. Our monitoring systems detected the disruption.
Mar 29, 19:40 UTC
identified
The issue has been identified as a hosting infrastructure problem external to our server. Our server logs show no internal errors, crashes, or resource exhaustion. We have contacted our hosting provider for investigation.
Mar 29, 20:30 UTC
monitoring
All services have been restored following a server restart. We are working with our hosting provider to determine the root cause and prevent recurrence. This is the second infrastructure-related disruption in 7 days.
Mar 29, 21:20 UTC
monitoring
Our hosting provider has confirmed the root cause: disk I/O errors on the physical host affected multiple servers, not just ours. All services are currently running normally. We are working with the provider on a permanent infrastructure resolution and will update when that is complete.
Mar 30, 11:15 UTC
resolved
This incident has been permanently resolved. Our hosting provider confirmed the root cause was disk I/O errors on the physical host server caused by orphaned virtual disk images from other customers. Six virtual machines were affected, not just ours. Our server has been migrated to a new, healthier physical host in a different data center with significantly lower density (6 servers vs 52 on the previous host). All services have been verified and are operating normally on the new infrastructure.
Mar 30, 18:16 UTC
All GABLVM services experienced an unplanned disruption lasting approximately 11 hours due to a hosting infrastructure issue. The root cause has been identified and resolved.
Mar 22, 2026
to Apr 15, 2026
major
6 updates
investigating
All services became unresponsive. Our monitoring systems have detected the disruption.
Mar 22, 21:09 UTC
investigating
We are investigating the cause of the service disruption. All services including the website, Quran Player, Prayer Times, and Islamic Calendar are affected.
Mar 23, 08:15 UTC
identified
The root cause has been identified as a hosting infrastructure issue. The server was operating with insufficient memory due to a provider configuration error. We are working with our hosting provider to resolve this.
Mar 23, 08:30 UTC
monitoring
All services have been restored. Our hosting provider has corrected the memory allocation, increasing available resources to the full contracted amount. We are monitoring all services to ensure stability.
Mar 23, 09:00 UTC
monitoring
Our hosting provider has confirmed the root cause and applied a fix. Additional system logging and automated health monitoring have been implemented to detect similar issues proactively.
Mar 23, 10:00 UTC
resolved
This incident is fully resolved. The root cause was a hosting provider configuration error that allocated insufficient server resources. The issue has been corrected and verified. A full postmortem is available on our blog. Preventive measures include persistent system logging, automated biweekly maintenance, and direct infrastructure monitoring access.
Mar 23, 14:30 UTC
Routine security updates were applied and verified. All services are operating normally.
Mar 22, 2026
maintenance
minor
1 update
resolved
Security updates applied and system restarted. All services verified and operating normally. No user-facing impact.
Mar 22, 12:09 UTC
The events page continued to display Upcoming status for approximately 5 minutes after the YouTube livestream went live for Ramadan Night 30. This was caused by two issues: the YouTube API proxy was caching the Upcoming response, and the YouTube sync was overwriting the Ongoing status set by the scheduled time check. Both issues have been resolved.
Mar 19, 2026
minor
4 updates
investigating
Ramadan Night 30 livestream started on YouTube but the events page still displayed Upcoming status instead of Live.
Mar 19, 02:35 UTC
identified
Two root causes identified. First, the YouTube API proxy was caching the Upcoming response, preventing the Live status from being returned. Second, the YouTube sync was overwriting the Ongoing status back to Upcoming when YouTube had not yet confirmed the stream as live.
Mar 19, 02:36 UTC
monitoring
Deployed two fixes. Removed caching on Upcoming responses so status changes are detected immediately. Prevented the YouTube sync from downgrading events from Ongoing back to Upcoming. Event manually set to Live and confirmed working.
Mar 19, 02:38 UTC
resolved
Events page now correctly displays Live status with 218 concurrent viewers. Both fixes verified in production. Future livestream status changes will be detected without caching delays.
Mar 19, 02:40 UTC
The English audio translation feature on the Quran Player was not playing. Listeners could enable the option, but no English audio played after the Arabic recitation; Arabic playback and the rest of the website were unaffected and no data was affected. A client-side initialization issue was identified and fixed, and English translation playback has been verified across all supported reciters.
Mar 9, 2026
to Mar 10, 2026
major
5 updates
investigating
We are currently investigating reports that the English audio translation feature on the Quran Player is not playing. Listeners can enable the option, but no English audio plays after the Arabic recitation.
Mar 9, 10:00 UTC
update
We are continuing to investigate this issue. The behavior is reproducible across browsers and with all supported reciters, which rules out caching on the visitor's side.
Mar 9, 14:30 UTC
identified
The issue has been identified and a fix is being implemented. A client-side initialization issue in the player was preventing the English translation option from taking effect when enabled.
Mar 10, 12:00 UTC
monitoring
A fix has been implemented and we are monitoring the results. English translation playback has been verified across all supported reciters. If the option still has no effect, reloading the page should pick up the fix.
Mar 10, 13:15 UTC
resolved
This incident has been resolved. The English audio translation feature is confirmed to be working normally, with the English translation playing after each Arabic verse. The feature was unavailable between March 9 and March 10, 2026. No data was affected.
Mar 10, 17:15 UTC
Two issues were identified with the prayer times page: (1) When the page transitioned to showing the following day's prayer schedule after Isha, the underlying time data used for next-prayer calculations was not updated, causing the wrong prayer to be highlighted. (2) Drupal's page cache was serving stale prayer time data for up to one hour, which could display incorrect times, the wrong Hijri date, and an inaccurate next prayer indicator. Both issues have been resolved. The prayer times page now always returns fresh data on each request.
Mar 8, 2026
to Mar 9, 2026
major
3 updates
identified
Identified that the raw prayer time data passed to the client-side JavaScript was not being updated when the display transitioned to the next day's schedule, causing incorrect next prayer calculations.
Mar 8, 23:00 UTC
resolved
Deployed fix to ensure raw time data is synchronized with the displayed schedule. Cloudflare cache purged to serve updated content immediately.
Mar 9, 00:00 UTC
resolved
Disabled Drupal page cache for the prayer times page to prevent stale data. The page now serves fresh prayer times on every request, ensuring accurate Iftar times, next prayer indicators, and Hijri dates. All caches purged.
Mar 9, 00:30 UTC
Prayer times displayed the next day's schedule for visitors in timezones behind UTC, across the Americas and the Pacific. The server requested times from the prayer API using the UTC date, but during evening hours in the United States the UTC date has already advanced to the next day. The result was a schedule shifted by about an hour, for example daylight time figures shown to a viewer still on standard time. The fix stops sending an explicit date, so the prayer API determines the correct local date from the viewer's coordinates.
Mar 8, 2026
major
3 updates
investigating
We are currently investigating a report that prayer times for Apple Valley, Minnesota showed Maghrib at 7:10 PM instead of the expected 6:09 PM. We are reviewing the data returned by the prayer times service.
Mar 8, 01:00 UTC
identified
The cause has been identified. The server requested prayer times using the UTC date. At 7:00 PM Central Standard Time on March 7, the UTC date had already advanced to March 8, so the service returned March 8 times calculated for daylight saving. Every time appeared roughly one hour ahead.
Mar 8, 01:15 UTC
resolved
This incident has been resolved. Prayer times requests no longer include an explicit date, so the prayer service determines the correct local date from the viewer's coordinates. Maghrib for Apple Valley now correctly shows 6:09 PM Central Standard Time. The cache was cleared. No data was impacted.
Mar 8, 01:30 UTC
Planned migration of all GABLVM services to an upgraded hosting environment with improved performance, reliability, and security. All services were migrated and verified with zero data loss and no user-facing downtime.
Mar 8, 2026
to Mar 13, 2026
maintenance
minor
4 updates
scheduled
A scheduled infrastructure migration has been planned to move all GABLVM services to an upgraded hosting environment. This migration is expected to improve overall performance and reliability. No user-facing downtime is anticipated.
Mar 8, 19:00 UTC
in_progress
The migration is now underway. A full backup of all site data has been secured and transferred to the new environment. Provisioning and restoration are in progress. All services remain available during this time.
Mar 11, 20:00 UTC
in_progress
Site data has been fully restored on the new environment. Database integrity verified. DNS records have been updated and are propagating. SSL certificates have been issued and validated.
Mar 12, 21:00 UTC
completed
The infrastructure migration has been completed successfully. All services have been verified and are fully operational. Improvements include upgraded compute and memory resources, enhanced security hardening, and a new transactional email platform. No data loss occurred and no user-facing downtime was experienced during the migration window. Thank you for your patience.
Mar 13, 02:00 UTC
February 2026
On February 28, 2026, we migrated our email delivery to a new infrastructure provider to improve cost efficiency and long-term scalability. During a window on March 1 to 2, 2026, the new provider experienced an outbound delivery issue caused by a false positive in their spam protection system, which temporarily blocked some legitimate messages. Ticket notifications, account registration, password resets, and newsletter delivery may have been affected. The provider resolved the issue on March 2, and all email delivery is operating normally.
Feb 28, 2026
to Mar 2, 2026
minor
4 updates
investigating
On February 28, 2026, we migrated email delivery to a new infrastructure provider. SPF, DKIM, and DMARC DNS records were updated for the new service, and the deliverability score was verified at 10 out of 10. Ticket notifications, password resets, and status page alerts now route through the new provider.
Feb 28, 06:00 UTC
identified
Our new email provider experienced a false positive in their outbound spam protection filters. This temporarily blocked some legitimate outgoing messages across their platform during a window on March 1 to 2. The cause was on the provider's infrastructure, not our configuration.
Mar 1, 12:00 UTC
monitoring
The provider deployed fixes across their mail infrastructure, including corrected filtering parameters, safeguards against false-positive triggers, and normalization fixes. Email delivery has resumed normally. We have confirmed the new service is stable and have closed our previous provider subscription.
Mar 2, 12:00 UTC
resolved
This incident is resolved. All email delivery is operating normally, and the deliverability score remains 10 out of 10, with SPF passing, DKIM valid, reverse DNS valid, and no blocklist entries. No further action is required.
Mar 2, 18:00 UTC
A security middleware update introduced a service configuration error that caused error pages for any request not served from edge cache. Primarily affected the Islamic Calendar page and other pages with unique query parameters that bypass cache. Root cause identified and fixed within 33 minutes. Edge cache purged to clear any cached error pages.
Feb 22, 2026
major
3 updates
investigating
User reported encountering an error page on the Islamic Calendar page. The site appeared to work intermittently — cached pages loaded fine, but uncached requests returned an error.
Feb 22, 14:55 UTC
identified
Root cause identified: a newly deployed security middleware (BanMiddleware) had incorrect service wiring. Drupal's StackedKernelPass auto-prepends the HTTP kernel argument, which shifted all other arguments — causing a TypeError that crashed every uncached request.
Feb 22, 15:10 UTC
resolved
Fix deployed. Corrected the middleware service definition to match the expected framework pattern, added error handling so the middleware can never crash the site, and purged edge cache to clear any cached error pages. All pages loading normally.
Feb 22, 15:25 UTC
Prayer times API calls are now routed through our edge proxy at api.gablvm.org with Cloudflare edge caching. This reduces latency from 1-3 seconds to near-instant on cache hits worldwide. The migration was completed ahead of schedule during Ramadan 2026. Additionally, a timezone bug was identified and fixed where the server used UTC date instead of the user's local date, causing prayer times to show the wrong day's times for users in timezones behind UTC.
Feb 14, 2026
to Mar 8, 2026
maintenance
minor
1 update
completed
Prayer times API migration completed ahead of schedule. All API calls now route through api.gablvm.org with edge caching (7-day TTL for Quran data, 24-hour for prayer times). During testing, a timezone bug was discovered and fixed: the server was using the UTC date to request prayer times, which caused incorrect times for users in timezones behind UTC (e.g., showing tomorrow's CDT times instead of today's CST times in Minnesota). The fix lets the API auto-detect the correct local date from the user's coordinates.
Mar 8, 01:00 UTC
Changing the calculation method for a city with a non-Latin name, such as Kathmandu, Beijing, Cairo, or Moscow, could cause prayer times to fail. The location lookup returned city names in their local script when no language preference was set, and those names failed on re-lookup. The issue has been resolved and a safeguard added to request Latin-script results consistently.
Feb 11, 2026
minor
3 updates
investigating
We are currently investigating reports that prayer times fail when the calculation method is changed for cities with non-Latin names. Initial logs show the location service returning city names in non-Latin scripts.
Feb 11, 16:00 UTC
identified
The cause has been identified. When no language preference is set, the location lookup returns a city's name in its local script. On re-lookup after a method change, that name is rejected by the prayer times service, which does not accept non-Latin input.
Feb 11, 21:30 UTC
resolved
This incident has been resolved. A language preference is now sent with every location lookup, so city names are returned consistently in Latin script. The fix was verified with Kathmandu, Beijing, Cairo, and Moscow across all nine calculation methods. The server cache was cleared to remove stale entries. No data was impacted.
Feb 11, 22:00 UTC
Visitors who entered a city and country manually on the Prayer Times page could receive incorrect results. The location lookup did not reliably resolve city names to coordinates, and the next-prayer calculation used the viewer's local timezone instead of the entered city's timezone. Both issues have been resolved and verified across multiple global regions. Automatic location detection was not affected.
Feb 11, 2026
major
4 updates
investigating
We are currently investigating reports that the Prayer Times page returns incorrect results when a city and country are entered manually. The next-prayer indicator appears to follow the viewer's local timezone rather than the timezone of the entered city. Automatic location detection is not affected.
Feb 11, 06:00 UTC
identified
The cause has been identified. Two issues affect manual city entry. The location lookup does not reliably resolve some city names to coordinates, and the next-prayer calculation derives its time from the viewer's clock rather than the entered city's local timezone.
Feb 11, 07:30 UTC
monitoring
A fix has been implemented and we are monitoring the results. The location lookup, the next-prayer calculation, and the countdown timer now use the entered city's local timezone. We are verifying the result across multiple cities and timezone regions.
Feb 11, 11:30 UTC
resolved
This incident has been resolved. Prayer times, the next-prayer indicator, and the countdown now reflect the entered city's local time regardless of the viewer's location. The fix was verified across seven cities spanning the Americas, Europe, Africa, the Middle East, Asia, and Oceania. Automatic location detection was unaffected throughout. No data was impacted.
Feb 11, 12:45 UTC
Emails sent to support@gablvm.org were being received by our email routing service but were not being processed into support tickets. The email processing system was failing silently due to an internal configuration mismatch.
Feb 8, 2026
major
4 updates
investigating
We are investigating reports that emails sent to support@gablvm.org are not generating support tickets. Our email routing service is receiving the emails but the processing system appears to be failing silently.
Feb 8, 21:00 UTC
identified
Root cause identified: the email processing worker was reading the email subject incorrectly due to an interface mismatch, causing it to fail before the ticket could be created.
Feb 8, 21:30 UTC
monitoring
Fix deployed. The email worker now correctly reads the subject from message headers. A test email has been sent to verify end-to-end functionality.
Feb 8, 21:40 UTC
resolved
Confirmed working. Test email successfully created a support ticket with the correct subject, content, and confirmation emails. The email-to-ticket system is fully operational.
Feb 8, 21:48 UTC
Scheduled infrastructure update in preparation for Ramadan 2026. No downtime was expected or experienced.
Feb 7, 2026
to Feb 14, 2026
maintenance
minor
1 update
completed
Scheduled maintenance has been completed.
Feb 14, 02:42 UTC
January 2026
We migrated Quran Player audio files to a global content delivery network (CDN) to improve loading times and playback reliability worldwide.
Jan 25, 2026
maintenance
minor
7 updates
scheduled
Planning migration of audio files to improve performance and reliability.
Jan 25, 22:30 UTC
in_progress
Setting up content delivery infrastructure for global distribution.
Jan 25, 22:35 UTC
in_progress
Started uploading audio files to the new CDN infrastructure.
Jan 25, 22:37 UTC
in_progress
Upload completed successfully. All files verified and ready for use.
Jan 25, 22:40 UTC
in_progress
Updated Quran Player to use the new CDN. Testing audio playback.
Jan 25, 22:45 UTC
in_progress
Audio playback verified working correctly across all devices.
Jan 25, 23:00 UTC
completed
Migration complete. Audio now loads faster worldwide through global CDN distribution.
Jan 25, 23:08 UTC
Scheduled maintenance was performed on our security monitoring systems to improve threat detection accuracy.
Jan 20, 2026
maintenance
3 updates
scheduled
Scheduled maintenance to clear security tracking data following bug fixes in tracking and pattern learning systems.
Jan 20, 00:00 UTC
in_progress
Clearing security tracking data and monitoring logs. Database tables have been reset for accurate tracking going forward.
Jan 20, 00:10 UTC
completed
Data reset complete. Security dashboard now shows accurate tracking. No user-facing impact.
Jan 20, 00:15 UTC
Our automated backup system encountered a temporary storage issue. Backups have been optimized and are now running successfully.
Jan 17, 2026
to Jan 19, 2026
major
4 updates
investigating
Backup system showing storage errors. Investigating the issue.
Jan 17, 08:00 UTC
identified
Root cause identified: backup process was staging large media files unnecessarily, exhausting temporary storage.
Jan 18, 10:00 UTC
update
Optimized backup process to exclude large static media files that can be regenerated. Added cleanup procedures.
Jan 19, 10:00 UTC
resolved
Backup process fixed and tested. Backup size optimized and storage issues resolved.
Jan 19, 12:00 UTC
The Islamic Calendar and Prayer Times were not automatically updating after midnight. Users may have seen the previous day's date until refreshing. This has been fixed.
Jan 4, 2026
minor
2 updates
investigating
Page caching configuration causing stale content to be served on dynamic pages.
Jan 4, 09:00 UTC
resolved
Updated caching configuration to ensure Islamic Calendar and Prayer Times pages always display current data.
Jan 4, 10:00 UTC
The Islamic Events dropdown was defaulting to 2025 instead of 2026 when viewing the calendar in January 2026. This display issue has been corrected.
Jan 2, 2026
to Jan 4, 2026
minor
2 updates
investigating
Calendar defaulting to wrong year due to Hijri-Gregorian date conversion logic.
Jan 2, 10:00 UTC
resolved
Updated default year calculation to use the current Gregorian year correctly.
Jan 4, 00:00 UTC
Some users experienced incomplete Islamic events when viewing the full year calendar. The issue was related to how event data was being retrieved and has been resolved.
Jan 1, 2026
to Jan 9, 2026
major
3 updates
investigating
Reports of incomplete Islamic events display. Investigating the data source.
Jan 9, 10:00 UTC
identified
Root cause identified: external service rate limiting when processing multiple calendar requests.
Jan 9, 12:00 UTC
resolved
Implemented local date calculations to eliminate external service dependency. Islamic calendar now fully self-contained.
Jan 9, 14:00 UTC
December 2025
Screen reader users experienced an issue where navigation items were being announced incorrectly. This accessibility issue affected some users and has been fixed to ensure proper navigation announcements.
Dec 28, 2025
major
3 updates
investigating
Reports received that screen reader announces incorrect labels for navigation links. Investigating the issue.
Dec 28, 14:00 UTC
identified
Root cause identified: Accessibility enhancement script was incorrectly applying labels to navigation links.
Dec 28, 15:30 UTC
resolved
Fix deployed. Updated accessibility script to correctly target icon buttons only, preserving navigation link text.
Dec 28, 18:00 UTC
Screen readers were announcing additional descriptive text along with menu item names, causing verbosity for assistive technology users. Menu items now announce cleanly.
Dec 28, 2025
minor
1 update
resolved
Removed unnecessary description text from navigation menu items to improve screen reader experience.
Dec 28, 09:00 UTC
The "Skip to main content" accessibility feature required two clicks to work properly. This has been fixed for keyboard and screen reader users.
Dec 27, 2025
minor
1 update
resolved
Updated skip link target to properly focus on main content area for keyboard navigation.
Dec 27, 12:00 UTC
Automated backups were running at inconsistent times each day. The scheduling has been corrected to run at a fixed time.
Dec 25, 2025
to Dec 31, 2025
minor
2 updates
monitoring
Backup scheduling using relative intervals causing inconsistent backup times.
Dec 30, 00:00 UTC
resolved
Implemented fixed schedule backup job running at 1:00 AM daily for consistent timing.
Dec 31, 00:00 UTC
Enhanced our security monitoring capabilities to better detect and respond to potential threats.
Dec 23, 2025
minor
1 update
resolved
Fixed log parsing to correctly extract page paths from structured data format.
Dec 23, 10:00 UTC
Updated system components for improved compatibility and performance. No user-facing impact.
Dec 23, 2025
minor
1 update
resolved
Updated backup module to latest security release.
Dec 23, 08:00 UTC
Automated scheduled tasks were temporarily not executing. The issue has been identified and resolved, and all scheduled operations are running normally.
Dec 20, 2025
major
2 updates
investigating
Investigating reports that scheduled maintenance tasks are not executing as expected.
Dec 20, 00:30 UTC
resolved
Fix deployed. Server task configuration corrected and all scheduled maintenance jobs are running normally.
Dec 20, 02:00 UTC
The "Skip to main content" link was landing on the wrong page element. This accessibility feature now correctly takes users to the main page content.
Dec 12, 2025
minor
1 update
resolved
Repositioned skip link target to appear after breadcrumb navigation for better keyboard flow.
Dec 12, 10:00 UTC
The website logo was temporarily displaying as text instead of the image. This visual issue has been corrected.
Dec 12, 2025
minor
1 update
resolved
Updated site logo configuration to load correctly from the assets directory.
Dec 12, 01:00 UTC
Some system-generated emails contained incorrect website links. Email links now correctly point to the proper website address.
Dec 11, 2025
minor
1 update
resolved
Configured site URL settings for proper link generation in maintenance scripts.
Dec 11, 12:00 UTC
Some Quran reciters' audio was not playing correctly. The audio playback system has been updated to support all available reciters.
Dec 6, 2025
major
2 updates
investigating
Investigating reports of audio playback failures with certain reciters.
Dec 6, 01:00 UTC
resolved
Fix deployed. Audio playback system updated to handle all reciter formats consistently.
Dec 6, 03:00 UTC
The Quran Player was occasionally skipping surahs during continuous playback. The playback navigation has been fixed for seamless listening.
Dec 6, 2025
major
2 updates
investigating
Investigating reports of surahs being skipped during continuous playback.
Dec 6, 01:00 UTC
resolved
Fix deployed. Playback navigation corrected for seamless continuous listening.
Dec 6, 02:00 UTC