Radio.co Outage History
Radio.co is up right nowPingoru has recorded 61 incidents for Radio.co: 61 in the last 12 months and 23 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 4 | 38 of 720 (5%) |
| May 2026 | 2 | 2 of 744 (0%) |
| June 2026 | 2 | 184 of 720 (25%) |
| July 2026 | 5 | 202 of 744 (27%) |
| August 2026 | 7 | 368 of 744 (49%) |
| September 2026 | 10 | 158 of 720 (22%) |
| October 2026 | 9 | 125 of 744 (17%) |
| November 2026 | 0 | 0 of 123 (0%) |
Incidents, newest first
Major October 29, 2026 Stations Reporting Off Air 2h 33m Radio.co Studio, studio.radio.co, Studio Mobile App
Started Oct 29, 2026, 11:26 AM UTC· resolved Oct 29, 2026, 01:59 PM UTC
- investigating Oct 29, 2026, 11:26 AM UTC
We're currently investigating an issue with some stations reporting as Off Air. Whilst stations are remaining on air throughout, the incorrect status could be affecting web players in some circumstances. We're working to resolve this, and will provide updates as soon as possible. We thank you for your patience.
- resolved Oct 29, 2026, 01:59 PM UTC
We've now resolved the incident. Thanks for your patience.
Major October 27, 2026 Potential Downtime on a Station server 2m
Started Oct 27, 2026, 09:50 PM UTC· resolved Oct 27, 2026, 09:52 PM UTC
- resolved Oct 27, 2026, 09:52 PM UTC
Our monitoring software has detected the station server is back online. This incident has now been closed. If you continue to experience issues please contact [email protected] Thanks.
Major October 27, 2026 Downtime on Euromir Station Server 2h 5m Station Servers
Started Oct 27, 2026, 08:06 PM UTC· resolved Oct 27, 2026, 10:11 PM UTC
- investigating Oct 27, 2026, 08:06 PM UTC
Our monitoring software has detected potential downtime on the 'Euromir' Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. No other servers are affected.
- resolved Oct 27, 2026, 08:08 PM UTC
Our monitoring software has detected the station server is back online. This incident has now been closed. If you continue to experience issues please contact [email protected] Thanks.
- identified Oct 27, 2026, 09:42 PM UTC
Euromir has experienced intermittent availability since the start of the incident window. ###From our Server provider: This incident is caused by an electrical equipment issue. The replacement of the impacted electrical equipment in the rack is currently in progress.
- resolved Oct 27, 2026, 10:11 PM UTC
We would like to inform you that the incident affecting our Europa Station Server has now been resolved. ### RFO: - **Summary:** Server was temporarily unavailable. Affected stations are now back online. - **Impact**: Customers hosted on Euromir were temporarily unable to turn on their station or upload media - **Root cause:** This incident was caused by an electrical equipment issue at our partner data centre location in France. The components have been replaced and the server has ran through diagnostics with success.
Major October 11, 2026 Possible Degraded Performance on "S3" streaming pool 18h 12m Streaming Pools, s3.radio.co
Started Oct 11, 2026, 07:03 PM UTC· resolved Oct 12, 2026, 01:15 PM UTC
- investigating Oct 11, 2026, 07:03 PM UTC
Our monitoring system has detected potential degraded performance on the "S3" streaming pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
- resolved Oct 12, 2026, 01:15 PM UTC
We've now resolved the incident. Thanks for your patience.
Major October 9, 2026 Increased Listeners Reported in Real Time Statistics affecting some stations 3d 2h Streaming Pools, s2.radio.co, s3.radio.co
Started Oct 09, 2026, 09:09 AM UTC· resolved Oct 12, 2026, 11:14 AM UTC
- investigating Oct 09, 2026, 09:09 AM UTC
We're aware of an issue currently affecting some stations, where listener numbers are inflated above usual levels. We're currently investigating the issue, and will provide further updates shortly. Thank you for your patience.
- investigating Oct 09, 2026, 01:08 PM UTC
This is still being investigated by our development team. We apologise for the delay, we will provide a further update once available.
- investigating Oct 09, 2026, 03:47 PM UTC
Our development team is still working on this issue affecting some stations broadcasting on S2 or S3 listen links. Today you may see a reduction in the inflated Real-Time listener figures. We will be working on restoring the correct listener figures, and correcting any historical analytics over the next 48 hours. Our Weekly digest email has been suspended and will be re-issued once the issue has been corrected. Further updates will be provided when we know more. Once again we apologise for any inconvenience caused.
- investigating Oct 10, 2026, 08:24 PM UTC
Realtime listeners have now returned to expected levels on affected streams. The development team continue to work on reprocessing historical statistics for the last 3 days. Once complete, we will set this incident to resolved. Thanks for your patience and once again, apologies for any inconvenience caused.
- resolved Oct 12, 2026, 11:14 AM UTC
We've now resolved the incident. Thanks for your patience. A reason for outage report will be processed and published here once available.
- resolved Oct 16, 2026, 02:12 PM UTC
Reason for Outage: Inflated Listener Statistics **Summary** Between 7 and 10 October 2026, the listener statistics shown in your Radio.co dashboard were higher than the real number of people listening. Your stream itself was not affected: listeners could tune in and hear your station as normal throughout. The cause was an update we made to the system that produces your statistics. Your statistics are designed to leave out very brief connections, such as apps and automated services quickly checking a stream, so that only real listening is counted. The update let some of these brief connections slip through and be counted as listeners. We reversed the change, removed the incorrect figures and recalculated your statistics. All figures were fully corrected by 14 October. We are sorry. We know many of you rely on these numbers to understand your audience, report to sponsors and plan your programming, and for several days they were wrong. **When it happened** The problem began on Tuesday 7 October. We found and reversed the cause on the morning of Thursday 9 October, about 48 hours later. Correcting the figures already recorded was completed on Tuesday 14 October. * Wed 7 Oct: we released an update to the system that counts listeners, and the problem began. * Thu 8 Oct: listener figures across the platform rose sharply. * Fri 9 Oct: we reversed the update. Live listener figures returned to normal for almost all stations. * Sat 10 Oct: live figures were corrected for a small number of remaining stations, and we began recalculating past figures. * Tue 14 Oct: all past figures were corrected. **Who was affected and how** All stations were affected to some degree, though some saw much larger increases than others. Across the platform, reported listeners were roughly two and a half to three times higher than reality at the peak. During the incident, the following could show figures that were too high: * Live listener counts * Listener totals and charts for the affected period * Unique listener counts * Listener counts for individual tracks in your history * Average listening time * Bandwidth and usage figures **What was not affected:** * Your stream. Listeners could connect and listen normally the whole time. * Statistics from before 7 October. If you looked at or exported statistics covering 7 to 10 October before 14 October, those figures may have been too high. Please refresh or re-export them; the figures now shown are correct. **What went wrong and how we fixed it** On 7 October we released an update to the system that produces your listener statistics. Normally, very brief connections to your stream, such as apps and automated services checking it, are filtered out so that only real listening is counted. The update caused some of these brief connections to slip past that filter. Instead of being ignored, they were recorded as listeners who had stayed tuned in for hours, and over the following day the figures climbed. We fixed it in three stages: 1. Stopped the cause. On 9 October we switched off the update and went back to the previous, reliable way of counting. New figures were correct from that point on. 2. Removed the incorrect figures. We set aside the brief connections that had wrongly been counted, so they no longer count towards your statistics. Live figures recovered for almost all stations as soon as the update was reversed, and for the few remaining stations by 10 October. 3. Recalculated the past. We rebuilt every affected statistic for the period from the corrected records, checking the results against the weeks before the incident. This was completed on 14 October. **What we are doing to stop it happening again** The update that caused this has been withdrawn and will not return until it is proven safe. We are also strengthening how we look after your statistics, so that any problem like this is spotted and put right quicker, whatever its cause. * Fixing the underlying fault. We are correcting the fault before the update is reintroduced. * Automatic alerts. We are improving monitoring that alerts our team straight away if listener figures look unusual. * Faster aggregation. We are improving how quickly we can re-aggregate figures if they ever need it. **Our commitment** Accurate statistics are a core part of what we provide, and we fell short of that standard here. We have learned from it, and the steps above are designed to stop this happening again and to catch other problems sooner. If you have questions about your station's figures, or would like help checking a report you shared during this period, please contact our support team at [email protected]. Thank you for your patience during this incident.
Major October 5, 2026 Potential Downtime on a Station server 1d 3h
Started Oct 05, 2026, 06:14 AM UTC· resolved Oct 06, 2026, 09:19 AM UTC
- investigating Oct 05, 2026, 06:14 AM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
- resolved Oct 06, 2026, 09:19 AM UTC
Our monitoring software has detected the station server is back online. This incident has now been closed. If you continue to experience issues please contact [email protected] Thanks.
Major October 2, 2026 Potential Downtime on a Station server 13h 58m
Started Oct 02, 2026, 03:54 AM UTC· resolved Oct 02, 2026, 05:53 PM UTC
- investigating Oct 02, 2026, 03:54 AM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
- resolved Oct 02, 2026, 05:53 PM UTC
Our monitoring software has detected the station server is back online. This incident has now been closed. If you continue to experience issues please contact [email protected] Thanks.
Major October 2, 2026 Station Server Update Notification 3h 8m
Started Oct 02, 2026, 12:09 AM UTC· resolved Oct 02, 2026, 03:17 AM UTC
- investigating Aug 19, 2026, 07:10 PM UTC
We are resolved an issue affecting a small number of users where a station would stop requesting new tracks for playout, intermittently. An update was rolled out to general availability to address this on August 18th 2026. In order for your station to benefit from the new version, please restart at your convenience. If you experience any issues with your station please reach out to [email protected] Thank you Radio.co Support.
Major October 2, 2026 Skipped playlist items - Incident Write Up. 3h 8m
Started Oct 02, 2026, 12:09 AM UTC· resolved Oct 02, 2026, 03:17 AM UTC
- investigating Sep 04, 2026, 04:42 PM UTC
We have completed our initial investigation into the instances of playlist positions being skipped. This notice relates to the now resolved [incident](https://status.radio.co/notices/p7ybhw0nqhm7668o-playlist-position-is-skipped-in-some-instances). ### What happened We identified several contributing factors rather than a single fault. During periods of increased activity, particularly around the top of the hour, some requests to retrieve the next track were taking longer than expected or were not completed within the required timeframe. In these cases, the system could move on to the next playlist item. This was made more noticeable by the way our platform was scaling to handle these periods of increased demand. We also identified two related issues during the investigation. Changes being prepared for an upcoming feature had an unintended impact on database performance, while a separate reporting issue meant some very short tracks, such as jingles, could play correctly but not appear in Playout History. Strict track separation rules could also increase the time required to find a suitable next track and, in some cases, result in a playlist tag being skipped. ### What we changed During the incident we made a number of changes to improve playout performance and reduce the likelihood of playlist items being skipped. These included: - Increasing the resources available to the services responsible for retrieving upcoming tracks. - Increasing the number of instances of those services running at all times. - Adding extra capacity around the top of the hour, when demand is typically highest. - Improving request handling and increasing relevant timeouts. - Optimising how track separation rules are processed. - Temporarily disabling the part of our upcoming Early Access feature which was affecting database performance while that work is further optimised. - Fixing the reporting issue affecting short tracks and jingles. These changes resulted in a significant reduction in occurrences during our monitoring period. ### What happens next - We are continuing work to improve response times and platform performance, particularly during periods of increased activity around the top of the hour. - We are also improving monitoring and alerting across the shared platform infrastructure so that similar performance degradation can be identified earlier. - Further changes planned as part of our Early Access functionality will also change how this information is handled by the playout system, removing some of the dependencies involved in this incident. - We have scheduled an internal post incident review to look at the wider incident, the contributing factors and any further changes we should make as a result. We apologise to customers affected by this issue and appreciate your patience while we investigated and implemented these changes.
Major September 29, 2026 Potential Downtime on a Station server 17h 7m
Started Sep 29, 2026, 03:03 AM UTC· resolved Sep 29, 2026, 08:10 PM UTC
- investigating Sep 29, 2026, 03:03 AM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
Major September 26, 2026 Potential Downtime on a Station server 1d 12h
Started Sep 26, 2026, 07:14 PM UTC· resolved Sep 28, 2026, 08:07 AM UTC
- investigating Sep 26, 2026, 07:14 PM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
Major September 26, 2026 Potential Downtime on a Station server 2h 42m
Started Sep 26, 2026, 05:35 AM UTC· resolved Sep 26, 2026, 08:18 AM UTC
- investigating Sep 26, 2026, 05:35 AM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
Major September 22, 2026 Possible Degraded Performance on "S4" streaming pool 41m
Started Sep 22, 2026, 03:57 PM UTC· resolved Sep 22, 2026, 04:38 PM UTC
- investigating Sep 22, 2026, 03:57 PM UTC
Our monitoring system has detected potential degraded performance on the "S4" streaming pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
- resolved Sep 22, 2026, 04:38 PM UTC
Our monitoring system has detected the affected node is back online. Normal service on the "S4" streaming pool has resumed.
Major September 22, 2026 Possible Degraded Performance on "Streamer" pool 42m Streaming Pools, streamer.radio.co
Started Sep 22, 2026, 03:56 PM UTC· resolved Sep 22, 2026, 04:38 PM UTC
- investigating Sep 22, 2026, 03:56 PM UTC
Our monitoring system has detected potential degraded performance on the "Streamer" pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
- resolved Sep 22, 2026, 04:38 PM UTC
Our monitoring system has detected the affected node is back online. Normal service on the "Streamer" pool has resumed.
Major September 22, 2026 Possible Degraded Performance on "S5" Streaming pool 42m
Started Sep 22, 2026, 03:56 PM UTC· resolved Sep 22, 2026, 04:38 PM UTC
- investigating Sep 22, 2026, 03:56 PM UTC
Our monitoring system has detected potential degraded performance on the "S5" streaming pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
- resolved Sep 22, 2026, 04:38 PM UTC
Our monitoring system has detected the affected node is back online. Normal service on the "S5" streaming pool has resumed.
Major September 22, 2026 Possible Degraded Performance on "Stream" pool 1h 11m
Started Sep 22, 2026, 03:23 PM UTC· resolved Sep 22, 2026, 04:35 PM UTC
- investigating Sep 22, 2026, 03:23 PM UTC
Our monitoring system has detected potential degraded performance on the "Streaming" pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
- resolved Sep 22, 2026, 04:35 PM UTC
Our monitoring system has detected the affected node is back online. Normal service on the "Streaming" pool has resumed.
Major September 22, 2026 Possible Degraded Performance on "Streaming" pool 1h 16m
Started Sep 22, 2026, 03:22 PM UTC· resolved Sep 22, 2026, 04:38 PM UTC
- investigating Sep 22, 2026, 03:22 PM UTC
Our monitoring system has detected potential degraded performance on the "Streaming" pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
- resolved Sep 22, 2026, 04:38 PM UTC
Our monitoring system has detected the affected node is back online. Normal service on the "Streaming" pool has resumed.
Major September 18, 2026 Potential Downtime on a Station server 10h 43m
Started Sep 18, 2026, 12:13 AM UTC· resolved Sep 18, 2026, 10:56 AM UTC
- investigating Sep 18, 2026, 12:13 AM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
- resolved Sep 18, 2026, 10:56 AM UTC
We've now resolved the incident. Thanks for your patience.
Major September 5, 2026 Potential Downtime on a Station server 8h 38m Station Servers
Started Sep 05, 2026, 03:38 AM UTC· resolved Sep 05, 2026, 12:16 PM UTC
- investigating Sep 05, 2026, 03:38 AM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
- resolved Sep 05, 2026, 12:16 PM UTC
This was a false alarm, there was no real problem.
Major August 21, 2026 Track fading may not function as expected when fade markers are offset. 13d 23h Station Servers
Started Aug 21, 2026, 09:00 AM UTC· resolved Sep 04, 2026, 08:33 AM UTC
- investigating Aug 24, 2026, 04:37 PM UTC
We are aware of some instances where track fading may not function as expected in certain scenarios, especially if the incoming track has fade set to zero, or a lower fade duration than the outgoing track. Our development team is working to resolve this issue. Once we have more information we will update this report. Due to the nature of the issue we will need to undertake extensive testing before wider release.
- resolved Aug 25, 2026, 05:38 PM UTC
Work is continuing on this issue. Unfortunately we do not have an ETA at this time. Once we have more information we will provide an update.
- resolved Aug 26, 2026, 04:14 PM UTC
We are testing a solution internally and expect to publish this to affected stations once testing is verified. This will be within the next 24 hours. We will update this report once this has happened.
- resolved Sep 01, 2026, 03:31 PM UTC
We will be rolling out an update to crossfading on Wednesday 2nd September which restores previous behaviour. This rollout will require a station restart, however only needs to be carried out if your station fades are not as expected. We will provide another update once the rollout is complete. Thanks for your patience.
- resolved Sep 03, 2026, 12:59 PM UTC
We have rolled out the update across our fleet which restores the fades to expected behaviour. Please restart your station when convenient to load the new software update. If you continue to experience issues please reach out at [email protected] Once again we'd like to apologise for any inconvenience caused.
- resolved Sep 04, 2026, 08:33 AM UTC
We've now resolved the incident. Thanks for your patience.
Major August 19, 2026 Playlist position is skipped in some instances 15d 13h Radio.co Studio, Platform
Started Aug 19, 2026, 07:17 PM UTC· resolved Sep 04, 2026, 08:34 AM UTC
- investigating Aug 19, 2026, 07:17 PM UTC
We are investigating reports that playlists may not be starting from the expected position in some instances. Adjustments have been made to our platform in order to alleviate this while a longer term solution is sought. If you have reported this issue to support, this has been logged with our engineering team who are investigating. Further updates will be provided as this notice progresses. Thank you for your patience during this time,
- investigating Aug 20, 2026, 10:45 AM UTC
We've fixed the core issue, and are waiting for things to recover.
- investigating Aug 21, 2026, 08:24 PM UTC
Development have made some adjustments to the track fetch service around while they work on a permanent resolution. This should improve the situation with track ordering in most cases. We will provide a full update once available.
- investigating Aug 24, 2026, 04:24 PM UTC
We’ve deployed several improvements related to playlists skipping, and reports showing skipped tracks ### The changes now live include: - Increased request timeouts, which should reduce instances where track requests are not completed in time, including some skips around the top of the hour. - Improved handling of short tracks and jingles so they are recorded more accurately in Playout History. - Requires station restart We’re continuing to monitor the results of these changes and investigate the remaining instances of playlist positions being skipped. Further work on related playback and crossfade behaviour will follow once this investigation is complete. We’ll post another update as soon as we have more information. Thank you for your patience.
- resolved Aug 25, 2026, 05:43 PM UTC
Further work has been completed which has improved performance and reduced the occurrences of track skip events significantly. Changes now live: - Full review of our platform infrastructure scaling with additional performance improvements and fallbacks in place As per our update yesterday, a station restart addressed an issue affecting short tracks (such as Jingles) being missed from the playout report, despite being played. If you are still experiencing this issue, we advise to restart your station at a convenient time. We will provide further updates once known.
- resolved Aug 26, 2026, 04:30 PM UTC
Further optimisations have been made to the platform and we have seen a dramatic decrease in instances of skipped playlist items. The team continues to work on the matter to further improve playout in edge cases. The majority of track playouts should be as expected. We will provide another update within the next 24 hours.
- resolved Aug 27, 2026, 03:58 PM UTC
We’ve been monitoring the platform closely over the last 24 hours and have seen a significant reduction in occurrences. In some cases, this behaviour can happen when a station has strict separation rules enabled and the system is unable to find a suitable track within a reasonable timeframe. When this happens, a playlist tag item may be skipped as expected. To help reduce the likelihood of this occurring, we recommend relaxing your separation rules so that, where multiple rules are enabled, they do not exceed 120 minutes. If you continue to experience issues, especially if you do not have separation rules enabled, please contact us at [email protected] or reply to your existing support conversation. Once again we thank you for your patience during this time.
- resolved Sep 04, 2026, 08:34 AM UTC
We've now resolved the incident. Thanks for your patience.
Major August 17, 2026 Stations falling silent in some circumstances 1d 5h
Started Aug 17, 2026, 04:00 AM UTC· resolved Aug 18, 2026, 09:00 AM UTC
- resolved Aug 19, 2026, 07:06 PM UTC
An update has been rolled out to general availability to address this. In order for your station to benefit from the new version, please restart at your convenience.
Major August 15, 2026 Possible Degraded Performance on "Streams" pool 2d 11h
Started Aug 15, 2026, 08:56 AM UTC· resolved Aug 17, 2026, 08:39 PM UTC
- investigating Aug 15, 2026, 08:56 AM UTC
Our monitoring system has detected potential degraded performance on the "Streams" pool. The affected node has been removed from service until it is available again. Listeners will be re-routed to other nearby servers automatically. Once the affected node is restored we will reintroduce it to service.
Major August 7, 2026 Potential Downtime on a Station server 2h 12m
Started Aug 07, 2026, 04:42 PM UTC· resolved Aug 07, 2026, 06:54 PM UTC
- investigating Aug 07, 2026, 04:42 PM UTC
Our monitoring software has detected potential downtime on a Station Server. Our DevOps team has been informed and are working to investigate the problem. Further updates will be provided in due course. If your station has stopped broadcasting we apologise for the inconvenience caused.
- resolved Aug 07, 2026, 06:54 PM UTC
Our monitoring software has detected the station server is back online. This incident has now been closed. If you continue to experience issues please contact [email protected] Thanks.
Major August 7, 2026 Potential Downtime on a Station server 6m
Started Aug 07, 2026, 03:33 PM UTC· resolved Aug 07, 2026, 03:40 PM UTC
- resolved Aug 07, 2026, 03:40 PM UTC
Our monitoring software has detected the station server is back online. This incident has now been closed. If you continue to experience issues please contact [email protected] Thanks.