Users of the KakaoTalk and BiP messaging apps are reporting service disruptions across Russia. BiP users describe delays in sending messages and slow loading of media. On Downdetector, users report that messages in BiP are not delivered at all, while KakaoTalk is experiencing similar issues.
Both messengers gained popularity in Russia following the blocking of Telegram in 2025. At the same time, there are growing concerns about their security.
On July 29–30, 2026 Riposte monitoring from eight locations across Russia recorded a consistent blocking of three KakaoTalk infrastructure subdomains (api.kakao.com, channel.kakao.com, ka.kakao.com) at 7 out of 8 monitoring locations. It also detected widespread throttling of BiP’s media delivery and performance degradation of its web version. At the same time, the primary websites of both services — bip.com and kakao.com — remain accessible in most locations.
A similar pattern has been described by users and media outlets since July 24: the apps nominally work, but messages and media files fail to deliver. The data covers hourly measurements for July 29–30. This report will be updated as new data arrives.
This analysis follows the same methodology as Riposte’s earlier report on blocking of Apple and the App Store from July 20, 2026: that piece broke down the share of anomalous connections by carrier and observation point instead of collapsing everything into one overall percentage.
Timeline
| Date | What happened |
| December 2024 | According to Vedomosti, Roskomnadzor (Russia’s federal media and communications regulator) added KakaoTalk to its register of “organizers of information dissemination» (OID),” alongside WhatsApp, Skype, Wire, and Element — a status that requires storing user correspondence and handing it over on request |
| March 2026 | According to iXBT, KakaoTalk climbed from 428th to 9th place in the overall ranking and took 2nd place in the social apps category of the Russian App Store |
| March 2026 | BiP, developed by the Turkish carrier Turkcell, started gaining a Russian audience: according to the company, all user data is stored encrypted in data centers in Turkey and never leaves the country |
| Q2 2026 | According to MTS AdTech data cited by Kommersant, BiP’s audience grew 120% over the quarter to 4.3 million monthly active users, while KakaoTalk grew 80% to 1.26 million |
| ~July 24, 2026 | Users began reporting outages on both services |
| July 29, 2026 | Meduza reported user complaints about disruptions in both messengers for a second day in a row, citing the Telegram channel “Ostorozhno, Moskva” (“Careful, Moscow”); no official statement from Roskomnadzor (RKN) had appeared at that point |
What’s known from open sources
The symptoms users describe are the same for both services: messages get stuck in “sending” status, media files aren’t loading, but the app itself opens and otherwise works normally. According to Meduza, BiP messages arrive with a delay and media loads slowly. Downdetector shows that some users can’t open the app or don’t receive messages at all.
How to read the statuses: available, slow, blocked
Each connection in the measurement gets one of three statuses.
- Available: the server responded with code 200, 301, or 302, and the connection came up quickly.
- Slow: the server responded, but the delay exceeded 800 ms (the threshold at which users start to perceive the service as frozen).
- Blocked: the connection never came up at all and the TCP port stays closed, which is typical of a reset at the deep packet inspection (DPI) hardware level rather than a problem on the service’s own end.
There’s also a separate pattern where a response arrives only after about 8,000 ms. Technically that still counts as “slow” rather than “blocked,” but from the user’s perspective, this is indistinguishable from a dropped connection.
BiP: the site works, media and the web version lag behind
The main domain, bip.com, loaded successfully from 7 of 8 vantage points. BiP has been developed by the Turkish carrier Turkcell. The developer says that user data is stored in data centers in Turkey and never leaves the country; so, BiP doesn’t depend on US cloud infrastructure, which usually gets restricted first. However, media.bip.com (which serves photos and videos in chats) is reachable from only 3 out of 8 vantage points: Saint Petersburg, one of the Vladivostok nodes, and Kazan. The messenger’s web version web.bip.com is reachable only from 2 of 8 points: Saint Petersburg and Vladivostok. At the remaining nodes, both domains time out at around 8000 ms.
This is a consistent slowdown, not a block (no dropped connection). Users feel no difference though. It was impossible to load photos and videos in BiP from the majority of our points, and the web version was unusable.
KakaoTalk: the site opens, key APIs are blocked
The public site kakao.com can be opened from all 8 points, but with a consistent 1.2–1.5 second delay on the redirect, which looks like deliberate throttling rather than blocking. The domain kakao-talk.com works almost without issues: 7 of 8 points.
Three subdomains (api.kakao.com, channel.kakao.com, and ka.kakao.com) are blocked (the TCP connection is closed) at 7 of 8 points. These are infrastructure APIs (not part of the site’s front end) that the KakaoTalk app uses to authenticate and sync messages. According to Kakao’s official help documentation, login verification depends on SMS messaging to a short number. This can fail if the carrier blocks such messages as spam. So, three subdomains have been blocked while the main site remains accessible. It means one can open kakao.com in a browser, but can’t use the messenger app. The other nine KakaoTalk subdomains are technically reachable from every point, but with delays of 850 to 3400 ms, which also qualifies as “slow.”
The key moment: three columns (api.kakao, channel.kakao, and ka.kakao) are almost solid red, and only one row (Omsk) is green across those three columns. The kakao.com column and most other kakao subdomains are uniformly yellow across all eight points. This means a systemic slowdown rather than a block. The BiP columns show a mix of green and yellow, with no red in any cell.
Of the 8 monitoring points, Omsk is the only one with access to all three blocked KakaoTalk subdomains. Deep packet inspection hardware in Russia operates at the level of individual carriers and network nodes rather than under one central rule, so the picture can vary by region.
Mechanics
The signature visible in the data is typical of interference at the secure-connection-establishment level. The server is unreachable over HTTPS, the TCP port can be either open or closed, and the roughly 8,000 ms delay matches a response timeout. This pattern means KakaoTalk’s servers are reachable from the internet overall. The connection breaks somewhere between the measurement point and the target, not because the service itself is down.
Partial degradation that varies by node is characteristic of interference through technical measures for countering threats (TSPU), the deep packet inspection hardware Russian carriers have deployed since 2020. According to the Roskomsvoboda project (a Russian digital rights group), TSPU can not only block access but also selectively throttle specific services and protocols, which matches the pattern seen here: a full block on three Kakao API subdomains combined with a widespread slowdown of the other targets. A situation where a target is reachable at one point but not at a neighboring one remains a typical sign of targeted interference rather than a global service outage.
What the parties say
As of July 30, 2026, Roskomnadzor hasn’t officially responded to the BiP and KakaoTalk outages. Meduza notes that complaints have been coming in for a second day, with no official statement from RKN on the cause. Staying silent on this particular case doesn’t mean RKN never comments on episodes like this. On July 14, 2026, when users complained about outages affecting Apple, Google, and GitHub, RKN’s press service told Interfax directly that the agency “does not restrict access” to those services. This time, though, the silence isn’t limited to RKN: no public comments from Turkcell (BiP’s developer) or Kakao Corporation could be found by publication time either.
What this means for BiP and KakaoTalk users
If photos and videos won’t open in BiP, or the BiP web version won’t load, this data suggests a widespread issue at the time of measurement, not an isolated glitch: availability was 25–37.5% across the eight points. The KakaoTalk symptom is just as easy to recognize: the messenger opens in the browser but won’t sync messages or let you log in, because the blocked components are the infrastructure API subdomains, not the site itself (reinstalling the app won’t help here).
Switching DNS providers probably won’t help here. The signature points to blocking of the connection itself, not DNS response spoofing. Getting around it will most likely require working at the transport layer (a VPN or proxy) rather than switching resolvers.
Open questions
Some questions don’t have answers yet because there isn’t enough data. It’s unclear why Omsk specifically keeps access to the three blocked Kakao subdomains when the seven other nodes don’t. Testing the hypothesis of regional TSPU rules will need further research. It also isn’t established whether kakao.com’s persistent “slow” status reflects deliberate throttling or simply distance from Kakao’s content delivery network (CDN); that needs further checking over time. And it’s unclear why media.bip.com and web.bip.com time out at most points while bip.com itself doesn’t. Different infrastructure for different subdomains remains a working hypothesis for now, not a confirmed fact.
Methodology
Data comes from eight independent servers across Russia (Saint Petersburg, two points; Perm; Vladivostok; Yekaterinburg; Kazan, two points; Omsk). This is a time series: measurements are recorded every hour over July 29–30, 2026, with the most recent one at the time of writing recorded on July 30 at 15:08 UTC. The material is updated as new data comes in. Threshold for “slow” status: response delay above 800 ms with an HTTP code received. Threshold for “blocked” status: the TCP connection doesn’t open.