Вайбкодинг · 1 октября 2026 г.
CDN Requests заменили название Edge Requests в Vercel
Vercel переименовал метрику Edge Requests в CDN Requests. Для большинства пользователей это косметическое изменение, но владельцам биллинговых интеграций нужно перенастроить сопоставления на стабильный SkuId.

Что изменилось и зачем это полезно
Vercel официально переименовал метрику Edge Requests в CDN Requests. По сути это только новое имя: тарифы, лимиты и способ подсчёта остались прежними. Новое обозначение появилось в панели использования, на графике Observability Events, в уведомлениях об использовании и в позициях счёта.
Польза от переименования — в ясности. Название CDN Requests подчёркивает, что речь идёт о запросах, обслуживаемых CDN Vercel, а не о какой-то отдельной «edge»-метрике. Для тех, кто отслеживает использование и анализирует расходы, новое имя делает связь между запросами и CDN более очевидной прямо в интерфейсе и счётах.
Практический контекст: что проверить в первую очередь
Если вы просто просматриваете панель управления и отчёты — ничего больше делать не нужно: сохранённые запросы и идентификаторы метрик не изменились, графики и уведомления продолжают работать с прежними настройками. То есть готовые дашборды и сохранённые поиски останутся валидными.
Если вы интегрируете биллинговые данные автоматизированно, обратите внимание на API биллинга. В ответах API поле ServiceName теперь возвращает новое название — CDN Requests. Интеграции, которые сопоставляют позиции счёта по значению ServiceName, могут неожиданно перестать срабатывать после переименования.
Чтобы избежать разрывов в обработке счёта, Vercel рекомендует для сопоставлений использовать поле SkuId. SkuId сохраняет стабильность при переименованиях продукта и остаётся неизменным, тогда как ServiceName может меняться. Переключение логики сопоставления на SkuId снизит риск регресса при будущих обновлениях имён.
Конкретные шаги для команд и интеграторов
1) Проверьте все места, где ваша система сверяет или фильтрует позиции счёта по ServiceName. Это могут быть ETL-скрипты, автоматические правила маршрутизации затрат, или внутренние сопоставления в финансовых инструментах. План действий — заменить сопоставления по ServiceName на сопоставления по SkuId там, где это возможно.
2) Протестируйте обработку счетов и уведомлений после переключения. Для уверенности запустите прогон на исторических данных или на тестовой учетной записи: SkuId остаётся прежним, поэтому результаты должны совпадать с логикой, основанной на ServiceName до переименования.
3) Обновите документацию и оповестите команды. Укажите в документации новое имя метрики (CDN Requests) и сделайте пометку, что это прежние Edge Requests. Это поможет аналитикам и бухгалтерии быстро соотнести новые строки в счётах с уже знакомыми метриками.
4) Проверьте дашборды и уведомления на предмет текста и предупреждений. В интерфейсе и в отправляемых уведомлениях теперь будет «CDN Requests» — при необходимости обновите правила парсинга уведомлений или алертов, которые рассчитывали на старую формулировку.
Ограничения и риски
Главное ограничение — изменение касается только названия. Цены, лимиты и способ измерения использования останутся прежними. Не следует ожидать изменений в счётах по количеству или сумме из-за переименования само по себе.
Риск есть для тех систем, которые строго завязаны на строковые сопоставления по ServiceName. Если миграция на SkuId не выполнена, автоматические правила разнесения затрат или интеграции с биллингом могут некорректно распознавать позиции в счёте после релиза.
Ещё одна техническая деталь: метрики и алиасы продуктов сохранили свои идентификаторы, поэтому сохранённые запросы продолжат работать. Но если сторонний процесс парсит текстовые поля счетов или уведомлений, его нужно проверить — текстовые совпадения в этих полях теперь будут содержать «CDN Requests».
Куда смотреть за деталями
Vercel сослался на документацию по тарифам и использованию CDN как на основной источник подробностей о метрике. Для изменения сопоставлений биллинга и для проверки стабильности идентификаторов рекомендуется изучить разделы, описывающие поля API биллинга, особенно SkuId и ServiceName.
Если ваша команда использует автоматические интеграции третьих сторон, проверьте их совместимость с новым ServiceName и при необходимости переключите логику на использование SkuId.