Dmitriy Kononov
Let’s talkContact

News and analysis

Yandex's October outage: what to do when ads, analytics and payments all sit in one window

A timeline of the Yandex outage from Cossa, Unisender and Cloudflare, and what I would check at a company whose leads, ads and payments depend on one service.

From October 8 to 11, after attacks on three Yandex data centers, businesses in Russia lost the Direct ad account, Metrica and part of their payments through Yandex Pay all at once. The ads kept running and spending money, and leads from websites kept coming in, but not everyone could see them. For a business owner this is the week he finds out where his data lives: with him, or with one vendor, in one window.

What happened, day by day

On October 16, Unisender put together a timeline: the data center in the Ryazan region was hit on October 8, Kaluga on the 9th, and on the 11th the facility in Vladimir stopped. The most noise was around Yandex Pay: people couldn't check a balance, pay for a purchase or transfer money. According to Kommersant, as quoted by Unisender, from October 10 advertisers couldn't get into their accounts to stop campaigns, while the ads kept drawing down the budget. The same post has examples of how companies behaved: Dodo Pizza wrote right away that orders couldn't be placed through the app and promised refunds.

On October 13, CNews reported that overnight on October 13 Yandex Pay partially recovered: card and sticker payments were working in full, the online service was still unstable.

On October 20, Cossa published the Yandex Advertising statement on restoring Direct's core functionality, with the sequence: accounts unavailable from October 11, the Direct account back on the 15th, Metrica, AppMetrica and the Direct API on the 16th, Direct's main functions on the 20th. From October 11 to 14, campaigns kept showing, limits were respected, and the statistics for those days were saved and will appear as they are processed. On October 23, Cossa quoted Yandex's commercial director Gleb Dobroradnykh: advertiser activity is back to the level before the attacks, budgets are growing.

The most useful text of the week, in my view, was written by Maxim Volkov of Volkov Digital; Cossa published it on October 19. Metrica broke on the night of October 12 and was down for four days. On a brand catalog that normally gets about 2,200 visitors a day, the 13th showed a few hundred visits and the 14th a dozen. On October 15 at 15:40 Metrica finished counting both days: 2,160 and 2,091. The numbers came back; the decisions made on the zeros won't. His rule I would sign in full: when the graph drops off on every channel at once, change nothing for a day and open the CRM first. Then comes his list of what quietly hangs on Yandex: dashboards that reload “yesterday only,” where the zeros for October 13 and 14 will stay forever; Direct auto-strategies that learn from Metrica goals; bonuses tied to those goals. On October 14 he set up Umami on his own server as a backup counter.

On October 14, Cloudflare looked at the outage from the other side: on October 11, traffic from the Yandex Search network fell 99% below normal, the cloud 90%, and malicious automation from Yandex Cloud addresses moved to other hosting providers. There's no reason to weaken a site's defenses because one provider is down.

What this means for a company without its own IT department

Take a car rental company in season. Ads in Direct, leads through a form on the site, the contractor reports on Metrica goals, customers pay deposits through a payment service. On October 12 the owner sees visits go to zero on one screen, the account won't open on a second, and on a third a customer writes that the payment isn't going through. If every lead is written to its own database or a CRM, he opens the list, sees yesterday's bookings and understands that only the storefront broke.

The conclusion: the data you use to make decisions about money has to live somewhere you can get into without Yandex, Google or any other single window. A CRM or your own database, as long as it's a second place.

How it works in my projects

In 2022 I set up a PDR company in the US with its own server on Debian in Google Cloud. In 2023 we moved from Google Sheets to MariaDB, I moved the company's website from shared hosting to our server, and I connected its forms to the CRM and the app. Today leads from the site, the forms and IVR calls land in our own database and in the super app, and GoHighLevel went from the main CRM to a supporting one. If a third-party service goes down tomorrow, the day's leads stay in our database. Since 2022 we have had no serious outages that needed a recovery.

At a car rental company in Cape Town, where I was brought in in October 2024, AmoCRM stayed the center for customers and deals, while booking on the site, documents and the calendar logic run on their own server. Payment there is verified against a screenshot the customer attaches during the process. There's no automatic reconciliation with the bank, but in a week when the payment service has problems, car handovers don't stop.

What I would do after this week

  • Check where leads from the site are written. If it's only the counter and an email, add a record in your own database or CRM.
  • Agree with the contractor and the sales department in writing: October is counted by leads in the CRM.
  • Rerun the dashboard reload for October 1 to 15 and compare the visits for October 13 with the Metrica interface.
  • Put a second counter on your own server. I haven't tried Umami myself, but I support the idea of a backup count: how many people came and from where, without session recording.
  • Keep a second way to accept money and a prepared message for customers in case of an outage. The Dodo example from the Unisender post works as a template.

Related reading

On why a system needs its own center that doesn't depend on someone else's accounts: the article The server: data, access and process execution. Service areas: infrastructure you can release and restore and a CRM connected to how the team works. Cases: technical partner to a PDR company in the US and car rental in South Africa with booking and AmoCRM. On the same topic: a backup nobody has restored and how to read news about moving to the cloud. Earlier I wrote that a backup becomes protection after a verified restore and about how not to lose real inquiries when filtering traffic. If you want to find out where your leads live: Discuss your task.