Stop monitoring systems; start monitoring outcomes

When millions of conversations flow through your platform daily, reliability isn’t just a technical metric – it’s the foundation of customer trust.

Когда через вашу платформу ежедневно проходят миллионы разговоров, надёжность — это не просто технический показатель, а основа доверия клиентов.

At Intercom, where our AI Agent Fin resolves millions of customer inquiries autonomously, reliability starts with one essential question: Can our customers do the job they’re hired us to do?

В Intercom, где наш AI-агент Fin автономно решает миллионы клиентских запросов, надёжность начинается с одного главного вопроса: могут ли наши клиенты делать ту работу, ради которой они нас наняли?

This question has led us to develop what we call “heartbeat metrics” – vital signs that instantly tell us if our systems are truly serving their purpose. These metrics cut through the noise of complex monitoring dashboards and provide immediate clarity on customer impact. When a heartbeat metric drops, we don’t wait for customer complaints. We act immediately.

Этот вопрос привёл нас к разработке того, что мы называем «метриками пульса» (heartbeat metrics) — жизненных показателей, которые мгновенно сообщают нам, действительно ли наши системы выполняют своё предназначение. Эти метрики прорезаются сквозь шум сложных дашбордов мониторинга и дают немедленную ясность относительно влияния на клиента. Когда метрика пульса падает, мы не ждём жалоб клиентов. Мы действуем немедленно.

In this post, I’ll walk through what heartbeat metrics are, how we use them to define our Fin and Platform SLAs, and how you can create your own “heartbeat” to keep your engineering teams aligned and your customers happy – even as your systems grow increasingly complex.

В этом посте я разберу, что такое метрики пульса, как мы используем их для определения SLA нашего Fin и платформы, и как вы можете создать собственный «пульс», чтобы держать ваши инженерные команды слаженными, а клиентов — довольными, даже по мере того как ваши системы становятся всё сложнее.

What’s a heartbeat metric?

Что такое метрика пульса?

Modern systems are complex. Logs, dashboards, and tracing can help you debug issues once you know about them. Heartbeat metrics are about accelerating detection and understanding of customer impact. Think of it as a pulse check. If the pulse weakens, your customers can feel it instantly. A heartbeat metric is the clearest signal you can get that your product is alive and doing its job.

Современные системы сложны. Логи, дашборды и трассировка помогают отлаживать проблемы, как только вы о них узнали. Метрики пульса нужны для того, чтобы ускорить обнаружение и понимание влияния на клиента. Думайте об этом как о проверке пульса. Если пульс слабеет, ваши клиенты чувствуют это мгновенно. Метрика пульса — это самый чёткий сигнал, который вы можете получить о том, что ваш продукт жив и делает свою работу.

For Intercom, that job is conversations. So, our fundamental heartbeat metric is the rate of new messages and replies across Intercom. For Fin, it’s successful AI responses. If those dip, it’s hitting your ability to connect. It might be a database failover, a misconfigured fleet, or a bad code change – it doesn’t matter. What matters is that it’s hitting customers’ ability to use Intercom.

Для Intercom эта работа — разговоры. Поэтому наша основополагающая метрика пульса — это частота новых сообщений и ответов по всему Intercom. Для Fin это успешные AI-ответы. Если они проседают, это бьёт по вашей способности устанавливать связь. Это может быть переключение базы данных на резервную, неправильно сконфигурированный флот серверов или плохое изменение в коде — неважно. Важно то, что это бьёт по способности клиентов пользоваться Intercom.

We’re not alone in having a concept like this. Amazon tracks order volume as their heartbeat. Affirm watches checkout attempts. If those numbers fall below expected levels, they don’t wait for a support ticket, they investigate immediately. Because they know their customers’ success depends on it.

Мы не одиноки в том, что имеем подобную концепцию. Amazon отслеживает объём заказов как свой пульс. Affirm следит за попытками оформления заказа. Если эти цифры падают ниже ожидаемого уровня, они не ждут тикета в поддержку, а сразу начинают разбираться. Потому что знают, что от этого зависит успех их клиентов.

Not just any metric can be your heartbeat. The best ones share these traits:

Не любая метрика может стать вашим пульсом. У лучших из них есть такие черты:

Напрямую связана с ценностью для клиента: она должна отражать главную работу, ради которой наняли ваш продукт. Высокообъёмная и предсказуемая: объём позволяет системе обнаружения аномалий быстро замечать небольшие отклонения. Бинарная по духу: вам нужна метрика, у которой падение явно сигнализирует о поломке, а не просто о том, что «чуть медленнее обычного».

We’ve found that having a heartbeat metric:

Мы обнаружили, что наличие метрики пульса:

Обнаруживает проблемы быстрее, чем когда-либо могли бы сообщения пользователей или тикеты в поддержку. Удерживает наш фокус на том, что действительно важно для наших клиентов. Напрямую связана с нашим SLA. Это способ нашей системы сказать: «Да, обещание, которое мы дали клиентам, выполняется».

Of course, we still monitor all the usual suspects: latency, error rates, infrastructure health, etc. Heartbeat metrics don’t replace those – they complement them. They’re your shortcut to understanding customer impact, fast.

Конечно, мы по-прежнему мониторим всё привычное: задержки, частоту ошибок, состояние инфраструктуры и так далее. Метрики пульса не заменяют их — они их дополняют. Это ваш короткий путь к быстрому пониманию влияния на клиента.

Multiple heartbeats: How we monitor

Множество пульсов: как мы мониторим

Engineering reliably at scale means recognizing that complex systems need multiple vital signs. While the concept is simple, the implementation requires careful consideration of what truly matters to customers.

Надёжная инженерия в масштабе означает признание того, что сложным системам нужно несколько жизненных показателей. Хотя концепция проста, реализация требует внимательного учёта того, что действительно важно для клиентов.

At Intercom, we started simple: are customers creating messages at the expected rate?

В Intercom мы начали с простого: создают ли клиенты сообщения с ожидаемой частотой?

That signal was so strong we broke it down further, tracking different heartbeat metrics across Intercom’s core systems.

Этот сигнал оказался настолько сильным, что мы разбили его дальше, отслеживая разные метрики пульса по ключевым системам Intercom.

Each of our heartbeat metrics gives us a different perspective on whether users of Intercom, both human and AI, can do what they need to do:

Каждая из наших метрик пульса даёт нам отдельный угол зрения на то, могут ли пользователи Intercom — как люди, так и AI — делать то, что им нужно:

Fin отвечает вашим клиентам. Сотрудники отвечают в Inbox. Сотрудники взаимодействуют с интерфейсом Inbox. Пользователи на вашем сайте могут писать через Web Messenger. Пользователи в вашем приложении могут писать через Mobile Messenger.

Together, these metrics form a more complete picture of Intercom’s overall health. If even one of them drops, it’s a major customer-impacting problem.

Вместе эти метрики формируют более полную картину общего состояния Intercom. Если падает хотя бы одна из них, это серьёзная проблема, затрагивающая клиентов.

From detection to action

От обнаружения к действию

When the heartbeat alarm fires, speed is everything.

Когда срабатывает тревога по пульсу, скорость решает всё.

After months of reliable signal on its effectiveness, we connected it to automation to mitigate issues faster with engineers always double-checking. Here’s what happens when a heartbeat metric drops:

После месяцев надёжного сигнала о её эффективности мы подключили её к автоматизации, чтобы быстрее устранять проблемы, при этом инженеры всегда перепроверяют результат. Вот что происходит, когда метрика пульса падает:

Если мы только что развернули новый код в продакшен, мы автоматически откатываем его. Откат недавних изменений — это безопасная и быстрая операция. Мы автоматически создаём инцидент в incident.io и вызываем по пейджеру инженеров и командира инцидента. Если эта тревога сработала, скорее всего, нам понадобится полное реагирование на инцидент, включая обновления статус-страницы. Система автоматически предлагает первичные действия тем, кто реагирует первым. Например, мы используем функцию Investigations от incident.io, чтобы получить фору в поиске первопричин.

This automated response played out perfectly during a recent incident:

Этот автоматизированный отклик безупречно проявил себя во время недавнего инцидента:

On April 24th, a server issue slowed the Inbox, impacting teammates’ ability to use the Inbox. Our heartbeat metrics caught it fast, and we resolved it in 10 minutes. You can see in the second graph that end-user messaging was unaffected. This incident counted as downtime toward our SLA, and we shared a full root cause analysis publicly here.

24 апреля проблема на сервере замедлила работу Inbox, что повлияло на способность сотрудников пользоваться Inbox. Наши метрики пульса быстро это поймали, и мы устранили проблему за 10 минут. На втором графике видно, что обмен сообщениями с конечными пользователями не пострадал. Этот инцидент засчитался как простой в нашем SLA, и мы публично поделились полным анализом первопричин здесь.

Heartbeat-driven SLAs

SLA, основанные на пульсе

Our heartbeat metrics don’t just monitor – they also define our SLAs, keeping us accountable to our customers. We use these important metrics to measure two independent SLAs:

Наши метрики пульса не просто мониторят — они также определяют наши SLA, удерживая нас в ответственности перед клиентами. Мы используем эти важные метрики для измерения двух независимых SLA:

SLA основной платформы (Core Platform SLA): если ваша команда не может отвечать в Inbox или клиенты не могут писать через Messenger — это простой. Fin SLA: если Fin не может генерировать текстовые ответы, мы фиксируем простой.

Downtime, in relation to the SLA, is triggered when there’s a systemic issue affecting the platform. For example, a delay impacting a small feature wouldn’t count against the SLA (but will obviously be investigated as an incident). But if a customer loses the ability to execute core functionality, or if Fin is broadly failing to respond, that’s when it counts as downtime toward our SLAs.

Простой, в контексте SLA, фиксируется при системной проблеме, затрагивающей платформу. Например, задержка, влияющая на небольшую функцию, не засчиталась бы против SLA (но, очевидно, будет расследована как инцидент). Но если клиент теряет возможность выполнять основной функционал или если Fin массово не отвечает — вот тогда это засчитывается как простой против наших SLA.

Measurement matters. Many status pages stay green as long as an HTTP probe returns 200 OK, even when users are stuck. Heartbeat metrics close that gap by checking real customer outcomes, not just server responses.

Измерение имеет значение. Многие статус-страницы остаются зелёными, пока HTTP-проба возвращает 200 OK, даже когда пользователи застряли. Метрики пульса закрывают этот разрыв, проверяя реальные результаты для клиента, а не просто ответы сервера.

We don’t just look for absolute drops to zero. We use anomaly detection, tracking expected message patterns over time, and flagging when something looks off. When needed, we’ve additional tooling where we drop to a per customer level for investigating individual impact.

Мы не просто высматриваем абсолютные падения до нуля. Мы используем обнаружение аномалий, отслеживая ожидаемые паттерны сообщений во времени и отмечая, когда что-то выглядит не так. При необходимости у нас есть дополнительный инструментарий, который позволяет спуститься на уровень отдельного клиента, чтобы расследовать индивидуальное влияние.

A playbook for building your own reliability heartbeat

Плейбук для построения собственного пульса надёжности

If you don’t have a heartbeat metric yet, start simple. Here’s our playbook:

Если у вас ещё нет метрики пульса, начните с простого. Вот наш плейбук:

Определите обязательную задачу вашего продукта: что то единственное, чего клиентам абсолютно необходимо достичь, чтобы добиться успеха с вашим продуктом? Выберите метрику с объёмом: вам нужно что-то достаточно предсказуемое, чтобы быстро замечать аномалии, а не только полные отказы. Сделайте её бинарной по духу: если метрика падает, это должно быть из-за того, что что-то сломалось. Привяжите её к вашим алертам: сделайте её громкой и убедитесь, что она доходит до нужных людей. Используйте её для слаженности команд: когда пульс сбивается, все должны понимать, что это значит и что делать дальше. Держитесь за неё круглосуточно: надёжность — это не работа с 9 до 5.

Here’s a Datadog monitor we use for the Inbox heartbeat (Terraform syntax, simplified for clarity):

Вот монитор Datadog, который мы используем для пульса Inbox (синтаксис Terraform, упрощён для наглядности):

The power of heartbeat metrics lies in their simplicity. While modern systems grow increasingly complex, the fundamental question remains refreshingly straightforward: “Can our customers do what they came here to do?”

Сила метрик пульса — в их простоте. Хотя современные системы становятся всё сложнее, фундаментальный вопрос остаётся освежающе прямым: «Могут ли наши клиенты сделать то, ради чего они сюда пришли?»

At Intercom, our heartbeat metrics keep us honest, aligned, and fast. Define yours – it might become your most valuable signal.

В Intercom наши метрики пульса держат нас честными, слаженными и быстрыми. Определите свою — возможно, она станет вашим самым ценным сигналом.