When Yandex Metrica went down: running self-hosted Umami as backup analytics

I noticed Yandex Metrica was down on the first day of the outage: instead of reports it showed a placeholder, "The Metrica dashboard is temporarily unavailable." The dashboards of Direct, Yandex's ad platform, and Webmaster were unavailable too. It is now October 16. Webmaster has only just started opening, and not fully, while Metrica is still closed. The only place I have fresh traffic data is the Umami instance on my own server, where a traffic sources report takes a couple of minutes to pull.

The short version: if your analytics lives on someone else's infrastructure, their outage blinds you for as long as it lasts, and your ad settings are frozen at the same time. A second counter that writes visits and goals into your own database fixes the first problem. Server-side offline conversions fix most of the second.

What happened in October 2026

In early October 2026, several Yandex data centers were damaged. The Metrica and Direct dashboards showed placeholders, Webmaster was unavailable, and ads kept serving on the settings made before the outage. Counters on websites apparently kept collecting: the data could be pulled through the Metrica API, though Yandex never said how complete it was.

Yandex brought the mass-market services back first: Search, Alice, Maps, Taxi, Mail. Ad and analytics dashboards are recovering more slowly.

I did not see this coming. I set Umami up on October 13, mid-outage, because I wanted session recordings and heatmaps without handing data to a third party. It became my backup counter by accident.

What breaks when one tool holds all your analytics

I am keeping Metrica: Direct needs it, and it does its job. The trouble starts when its infrastructure fails, because everything goes at once.

Reports go first. The counter may keep collecting in the browser, but there is nowhere to look at the data. An API export helps only if you already have one set up, and even then nothing guarantees the outage days are complete. Every decision about the site in those days is made blind.

Ads are worse. Campaigns keep running on old settings, and there is nowhere to change a bid or budget or to switch off a bad campaign. And if goals stop reaching Metrica at some point, a conversion-optimizing bid strategy mistakes the outage for a conversion drop and adapts to a picture that is not real.

Then there is the loss that happens every day, outage or not. mc.yandex.ru is on every major block list, from uBlock Origin to AdGuard to browsers' built-in tracking protection. A visitor running one of them does not exist for Metrica. How many such visitors you have depends on your audience; with developers and B2B buyers it is noticeably more.

Picking a self-hosted tool

• Umami: Node.js and PostgreSQL, MIT license, no cookies. Visits, sources, goals, and since version 3 heatmaps and session replays too.
• Plausible CE: Elixir, PostgreSQL and ClickHouse, AGPL-3.0, no cookies. Visits, sources and goals, but ClickHouse needs a stronger server.
• Matomo: PHP and MySQL/MariaDB, GPL-3.0, sets cookies by default (can be disabled). The most complete replacement: e-commerce, funnels, a tag manager. Heatmaps and session recording are a paid plugin on self-hosted installs.
• GoAccess: written in C, reads web server logs, MIT, no JavaScript at all. Counts every request to the server but sees no in-page events.

I needed something that would sit on ordinary Node.js hosting next to the site and get by with one PostgreSQL database, and show session replays and heatmaps without a paid add-on. Umami fit, and the MIT license settled any question about what I can do with it. For an online store that needs e-commerce reports and sales funnels from day one, I would look at Matomo instead.

How my setup works

A separate subdomain on my own server

Umami runs as its own site on a subdomain, on the same hosting as the main site, with its own PostgreSQL database. Visit data never leaves the server. Shared hosting made the install harder than I expected; on a VPS with Docker, the official image starts with a single command.

The dashboard requires authentication. An analytics dashboard left open on a public address shows anyone your whole traffic picture, so lock it down before anything else.

Renamed endpoints against ad blockers

Block lists know Umami's default paths, /script.js and /api/send. Umami lets you rename both through its own environment variables, no Nginx proxy required:

# TODO: pick your own names, do not copy them from articles
TRACKER_SCRIPT_NAME=<your-name>.js
COLLECT_API_ENDPOINT=/api/<your-path>

On a subdomain of your own site, these requests look like ordinary first-party traffic. Keep the names out of public write-ups: once a path is published, it can land on a block list.

One function sends every goal to both systems

If goals fired from different places in the code, Metrica and Umami would drift apart sooner or later. So the site has one entry point:

export function track(event: AnalyticsEvent, data?: EventData) {
  // visitor declined analytics, or this is a service page
  if (isTrackingBlocked()) return;
  const payload = EVENT_SCHEMAS[event].parse(data ?? {});

  // Umami loads deferred: queue events until its script is ready
  if (window.umami) window.umami.track(event, payload);
  else if (pending.length < MAX_PENDING) pending.push([event, payload]);

  if (typeof window.ym === 'function') window.ym(YM_ID, 'reachGoal', event, payload);
}

Every event is validated against a schema, so a typo in a goal name breaks the build instead of a month of stats. If Metrica fails to load because it is blocked or down, the goal still reaches Umami, and the reverse holds too.

What must never reach analytics

Some pages carry a secret in the URL: an access token, a key in a link. Metrica records full URLs, so that token would sit in reports for anyone with access to the counter. On those pages neither counter loads, and Umami has an extra data-before-send hook that cancels any hit whose URL matches a blocked pattern. Password reset links, email confirmations and document links with keys deserve the same check on your site.

Cookies and consent

Umami sets no cookies. It derives the session on the server from a hash of the website ID, IP, user agent and a salt that rotates monthly by default (adjustable with SALT_ROTATION). The IP itself is not stored, and one person's visits cannot be linked across months.

I kept the consent banner anyway, because Metrica runs alongside and does set cookies. Umami is gated by the same choice: the hash still takes the IP address as input, and Russian law treats IP addresses as personal data. If a visitor declines, neither counter loads and no goal is sent.

Keeping ad conversions flowing

A second counter saves your reports, but Direct gains nothing from it: its bid strategies learn only from Metrica goals. To stop ads depending on a browser script, hand conversions to Metrica from the server as offline conversions. Store the yclid click ID (or Metrica's ClientId) with each lead, and when the CRM marks a sale, upload a CSV:

Yclid,Target,DateTime,Price,Currency
1837492018473920190,ORDER_PAID,1791963200,15400,RUB

DateTime is a Unix timestamp and must be in the past, or the API rejects the file. It goes to POST https://api-metrika.yandex.net/management/v1/counter/{counterId}/offline_conversions/upload as multipart/form-data and shows up in reports within three hours. While Yandex's dashboards are down, do not count on uploads either, but nothing is lost: conversions and click IDs wait in the CRM and go out once the API accepts files again. My own site does not sell through a cart, so I have not set this up yet; for a store with a CRM and Direct campaigns, it is the next step after a second counter, and it is the kind of setup I handle as part of website support.

FAQ

What should I do when my analytics provider goes down? Confirm it is a provider-side outage, mark the period as incomplete, leave ad settings alone for those days, and set up a second counter that stores data on your own server.

Is Umami a good Google Analytics alternative? For visits, sources, custom events, heatmaps and session replays, yes: it is light, cookieless and self-hosted. For e-commerce reports, funnels and a tag manager, Matomo is closer to a full replacement.

Does Umami need a cookie banner? Umami sets no cookies, but if your site also runs counters or ad pixels that do, you still need consent for those.

How do I hide Umami from ad blockers? Serve it from a subdomain of your site and rename the default paths with TRACKER_SCRIPT_NAME and COLLECT_API_ENDPOINT, using names you do not publish anywhere.