How to Integrate New Relic with Your Headless CMS

What is New Relic?

New Relic is an observability platform for monitoring applications, infrastructure, logs, metrics, traces, browser performance, synthetics, and alerts in one place. Engineering, SRE, DevOps, and product teams use it to see how production systems behave and to investigate incidents with time-series data. It’s one of the better-known tools in the monitoring and observability category, with support for OpenTelemetry, language agents, dashboards, NRQL queries, and alert policies.

Why integrate New Relic with a headless CMS?

Content changes can cause production issues just like code changes do. A new landing page can ship a 4 MB hero image, an article can include an invalid embed, a product page can lose a required field, or a redirect update can create a spike in 404s. If New Relic only sees deploys, errors, and infrastructure metrics, your incident timeline is missing a major source of change: what editors published and when they published it.

Connecting New Relic to a headless CMS lets you send structured content events into New Relic as custom events. Then you can ask questions like, "Did error rate increase after this product page was published?", "Which content type is tied to the slowest routes?", or "Did our LCP regression start after a campaign launch?" With Sanity, the Content Lake structures content as typed JSON, GROQ selects exactly the fields New Relic needs, and webhooks or Functions can send events the moment content is published, updated, or deleted.

The disconnected alternative is usually a mix of Slack messages, release notes, manual dashboards, and guesswork. That works until you have 30 editors, 12 markets, scheduled releases, and multiple frontends. The trade-off is that you need to be thoughtful about event volume and high-cardinality attributes in New Relic, especially if you publish thousands of documents per day. Send the fields that help debugging, not every field in every document.

Architecture overview

A typical Sanity and New Relic integration starts with a content mutation in the Content Lake, such as a document being published. A Sanity webhook can listen for publish, update, or delete events, and use a GROQ-powered filter like `_type in ["article", "productPage"] && !(_id in path("drafts.**"))` so only production content triggers the integration. The webhook calls a server-side endpoint, or you can run the logic in Functions without running separate infrastructure. That handler receives the document ID, fetches the current document from Sanity with `@sanity/client`, and uses a GROQ projection to select fields New Relic should receive, such as document type, slug, locale, owner, release name, and publish timestamp. References can be joined in the same query, for example `"owner": owner->name`. From there, the handler sends the payload to New Relic. For a long-running Node.js service, you can use the New Relic Node.js agent and `newrelic.recordCustomEvent()`. For short-lived serverless jobs, the New Relic Event API is often a better fit because it posts directly to `https://insights-collector.newrelic.com/v1/accounts/{accountId}/events` with an Insert API key. Once the event lands in New Relic, teams can query it with NRQL, add it to dashboards, and connect it to alert conditions. The end user still gets the web or app experience powered by Sanity, while your engineering team gets content-aware observability around that experience.

Common use cases

Step-by-step integration

1. 1

   Set up New Relic ingest

   Create or open a New Relic account, note your account ID, and create an Insert API key for the Event API. If you’re running a long-lived Node.js webhook service, install the New Relic Node.js agent with `npm i newrelic` and configure `NEW_RELIC_LICENSE_KEY` and `NEW_RELIC_APP_NAME`. For direct Event API posts, store `NEW_RELIC_ACCOUNT_ID` and `NEW_RELIC_INSERT_KEY` as secrets.

2. 2

   Model observability-friendly fields in Sanity Studio

   Add fields that help with debugging, such as `slug`, `locale`, `contentOwner`, `contentArea`, `releaseName`, and `observabilityTags`. Keep them typed in your Sanity Studio schema so the payload sent to New Relic is predictable JSON instead of parsed HTML.

3. 3

   Create a Sanity webhook or Function trigger

   In Sanity, create a webhook for publish, update, and delete events. Use a GROQ filter to limit traffic, for example `_type in ["article", "productPage", "landingPage"] && !(_id in path("drafts.**"))`. If you don’t want to run a separate webhook server, put the same logic in Functions and keep your New Relic keys in Sanity environment secrets.

4. 4

   Fetch the final document with GROQ

   Use `@sanity/client` inside the handler to fetch the current document from the Content Lake. Project only the fields New Relic needs, such as `_id`, `_type`, `slug.current`, `_updatedAt`, `locale`, and referenced owner data. This keeps New Relic events small and easier to query with NRQL.

5. 5

   Send custom events to New Relic

   For a Node.js service, call `newrelic.recordCustomEvent('SanityContentPublished', attributes)`. For serverless or Functions, post the same attributes to the New Relic Event API. Use stable attributes like `documentType`, `slug`, `locale`, and `contentArea`; avoid sending large Portable Text bodies or fields with unbounded values.

6. 6

   Test dashboards, alerts, and the frontend path

   Publish a test document, confirm the event appears in New Relic with a NRQL query like `SELECT * FROM SanityContentPublished SINCE 30 minutes ago`, and add a dashboard chart next to browser timing, error rate, and Apdex. Then load the published frontend route and verify that route-level metrics line up with the content event timestamp.

How Sanity + New Relic works

CMS approaches to New Relic

Keep building

Explore related integrations to complete your content stack.