> For the complete documentation index, see [llms.txt](https://docs.onelens.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onelens.cloud/integrations/cloud-and-cost-sources/connecting-to-newrelic.md). # Connecting to NewRelic Connect your New Relic account to OneLens for cost intelligence, ingest and seat cost attribution, sub-account cost allocation, and budget and anomaly alerting, using a dedicated read-only integration user and New Relic's own consumption data. {% hint style="warning" %} **How New Relic cost works here, read this first.** New Relic's API returns **billable quantities, not dollars**. The `estimatedCost` attribute was deprecated in May 2022, and no New Relic API exposes your contract rates. OneLens therefore combines New Relic's own billable metrics with a rate card you provide, so how closely your reported cost matches your invoice depends on those rates being right and current. See [How It Works](#how-it-works) before you build a chargeback model on it. {% endhint %} ## TL;DR * **What this does:** Reads billable consumption from New Relic's usage events via NerdGraph, applies your contract rates, and reports New Relic spend next to AWS, GCP, Azure, and OCI in OneLens. * **Time required:** \~20 minutes, most of it gathering your rate card. * **Who you need:** Someone who can create users in New Relic and view **Administration → Usage Summary**, plus whoever holds your New Relic contract or order form for the pricing. * **What OneLens reads:** New Relic's usage events (`NrMTDConsumption`, `NrConsumption`, `NrDailyUsage`) through a dedicated integration user. Read the honest caveat in [Security at a Glance](#security-at-a-glance) about what a New Relic User key can technically reach. ## Before You Start: What You Need to Know Three things about New Relic shape this integration, and it is better to know them now than at step 4. | Fact | What it means for you | | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **New Relic exposes usage, not cost.** `estimatedCost` was deprecated in May 2022 | You supply your contract rates. OneLens computes cost from New Relic's billable quantities and your rates. Every cost figure is modelled, not billed | | **New Relic has no scoped API keys.** A User key inherits the account permissions of the user who created it, and carries no per-key permission scope | You create a dedicated integration user and control exposure by which accounts you grant it. Log partitions can be restricted further on Pro and Enterprise; see [Security at a Glance](#security-at-a-glance) | | **The integration user can be a free Basic user** | The integration adds no seat cost. New Relic states plainly that "all users can query all data in the accounts they can access" and that "Basic users are free" | **Free tier:** New Relic gives you "access to 100 GB Ingested per month for free." OneLens prices the `*Billable` attributes rather than raw consumed quantities, and cross-checks the result against your **Usage Summary** page at connect time, so free usage is not priced as cost. New Relic reports free and billable consumption separately on some events, so step 3 includes that cross-check rather than assuming the arithmetic. ## What You'll Get Once Connected | Capability | What it does for you | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Unified Cost Explorer** | New Relic spend sits next to your AWS, GCP, Azure, and OCI cost in one view, on the same date and currency basis | | **Ingest Cost Breakdown** | Billable GB by consuming account and product line, so you can see which telemetry stream is driving the bill | | **Seat Cost Breakdown** | Billable Full Platform and Core user counts over time, separated from data cost, so a seat creep problem is distinguishable from an ingest problem | | **Sub-Account Attribution** | New Relic tags usage with `consumingAccountId`, so spend attributes to the account that generated it without you tagging anything | | **Anomaly Detection** | Alerts when billable ingest or seat count breaks its own pattern, so you catch a runaway log source inside the month | | **Budget Tracking** | Set New Relic budgets with OneLens alerting, on data cost, seat cost, or the total | | **Multi-Account Reporting** | One integration user covers every account it is granted, and OneLens reports across all of them in one currency | ## Security at a Glance New Relic's key model is weaker than most, and pretending otherwise would not survive your security review. The important row is the third one. | Question | Answer | | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What authentication is used? | A **User key** (format `NRAK-...`) created by a dedicated integration user, sent in the `API-Key` header to NerdGraph. | | Is the key read-only? | **In practice, for our use, yes.** OneLens issues only NRQL read queries against usage events. But see the next row: New Relic does not offer a key you can technically restrict. | | Can the key be scoped to billing data only? | **No, and this is the honest limitation.** New Relic has no scoped or permission-restricted API keys. A User key inherits the account permissions of the user who created it. That means a key which can read your usage events can also query telemetry in the same accounts. **OneLens's restriction to usage events is a contractual and audit commitment, not something New Relic's key model enforces.** | | So how do we limit exposure? | **Primarily by account.** You create a dedicated integration user and grant it only the accounts OneLens needs. New Relic's guidance notes you "don't need to use your Admin-level access for the integration" and that you can "assign only the accounts that you want to expose to the integration." | | Is there anything finer-grained? | **Yes, for logs.** New Relic's [Data access control](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/data-access-control/) lets you create policies restricting access to specific log partitions, and those policies do bind user keys. It covers log data only and requires Pro or Enterprise. If your sensitive data is in logs, this is a real additional control worth applying to the integration user. It does not restrict metrics, traces, or events. | | Does OneLens read our application data, logs, or traces? | **No.** OneLens queries `NrMTDConsumption`, `NrConsumption`, and `NrDailyUsage`, which contain consumption counters only. We maintain an audit log of every query issued against your account, available on request. | | Can OneLens change anything in New Relic? | **No.** OneLens issues NRQL read queries. It does not call NerdGraph mutations, so it cannot create users, change alerts, modify configuration, or delete data. | | Can OneLens see our billing or payment details? | **No.** Usage events carry consumption counters. Your invoices, payment method, and contract documents are not exposed by these queries. | | What happens if the integration user is deleted? | Its keys stop working. New Relic states that when a user is deleted, "their user keys are also deactivated and won't work." That is also your fastest revocation path. | | Is the key tied to an employee? | **No, and that is the point of the dedicated user.** A key created by a real person deactivates when that person leaves, silently breaking the integration. A dedicated integration user has no such dependency. | | How is data transmitted and stored? | All calls use HTTPS/TLS 1.2+. The key is encrypted at rest in OneLens using GCP KMS. | | What is the data retention policy? | OneLens retains ingested data for 12 months by default, configurable. On disconnection or a deletion request, data is purged within 30 days with confirmation. | | Where does the data live? | OneLens infrastructure runs on GCP. See the OneLens Trust & Security page for region details, SOC 2 report, and DPA. | ## Cost of the Integration OneLens deploys nothing into New Relic and the integration user is free. There is one caveat, and it applies only to some pricing models. | Item | What it is | Typical cost | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Integration user seat | A Basic user. New Relic states "Basic users are free" | $0 | | NerdGraph API calls | A handful of NRQL queries per day | $0 on Data + User pricing | | Compute Capacity Units | **On Core Compute and Advanced Compute pricing only.** New Relic measures those models in CCUs consumed by queries, alerts, API calls, and page loads, so OneLens's daily queries consume a small number | Negligible but not zero. See the note below | | Data ingest | None. OneLens sends nothing to New Relic, so it adds no billable GB | $0 | | Storage in your account | None. OneLens stores ingested data in its own infrastructure | $0 | | **Estimated total** | Sum of the above | **$0/month on Data + User. On CCU-based models, the cost of a few queries a day** | {% hint style="warning" %} **On the CCU caveat.** If you are on Data + Core Compute or have the Advanced Compute add-on, API calls consume CCUs, and New Relic notes that even free Basic users "can drive billing for usage-based features including the Advanced Compute add-on." OneLens runs a small fixed number of queries per day rather than polling, so the consumption is tiny, but we would rather name it than let you discover it. Tell us if you want the query count minimised and we will reduce cadence. {% endhint %} ## How It Works New Relic reports your own consumption back to you as queryable events inside your account. OneLens reads those events through NerdGraph, New Relic's GraphQL API, and applies your contract rates to turn quantities into cost. The events OneLens uses: | Event | What it holds | Why OneLens reads it | | ------------------ | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | `NrMTDConsumption` | Month-to-date aggregates, including `GigabytesIngestedBillable`, `FullPlatformUsersBillable`, and `CoreUsersBillable` | The primary source. These are the billable quantities, which is what your rates apply to | | `NrConsumption` | Hourly consumption, including `GigabytesIngested` by `productLine` and `consumingAccountId` | Trend and attribution detail, and the basis for anomaly detection inside a month | | `NrDailyUsage` | Daily breakdown, with synthetics detail facetable by monitor and location | Synthetic check volume, which is priced separately on many contracts | ### Why you supply the rate card This is the part that differs from most OneLens integrations, and it is worth understanding before you rely on the numbers. New Relic used to expose an `estimatedCost` attribute on its usage events. **It was deprecated in May 2022**, and New Relic now directs you to query consumption quantities instead. No New Relic API returns your negotiated per-GB rate, your per-user rates, your committed volume, or your tiered discounts. Those live in your contract, which is why the rate card has to come from you. So OneLens computes: ``` billable quantity (from New Relic) × your rate (from your contract) = cost ``` Every other cost platform connecting to New Relic works the same way, because there is no alternative. What matters is being clear about what that produces: {% hint style="info" %} **New Relic cost in OneLens is a modelled figure, not a billed one.** It reconciles to your invoice when the rate card is accurate and current. It will diverge if your contract changed mid-period, if you have tiered rates we were not told about, or if a commitment true-up lands outside the usage data. OneLens labels these figures as rate-card derived, and if your agreement changes, tell us so we can restate rather than quietly carrying stale rates forward. The quantities themselves are not estimates. `GigabytesIngestedBillable` and the billable user counts are New Relic's own billing metrics, the same numbers behind your invoice. The modelling risk lives entirely in the rates. {% endhint %} ### What granularity you get Cost breaks down by **consuming account**, by **product line**, and by **charge type** (data ingest, Full Platform seats, Core seats, synthetic checks). New Relic stamps usage with `consumingAccountId`, so sub-account attribution needs no tagging work from you. There is no per-service or per-application cost dimension in the usage events. If you need New Relic spend attributed to a team or service below the account level, the practical route is to structure sub-accounts along the lines you want to charge back, since that is the boundary New Relic itself reports on. ## What OneLens Will Access | Item | Detail | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Endpoint** | `https://api.newrelic.com/graphql` for US accounts, `https://api.eu.newrelic.com/graphql` for EU, `https://api.jp.newrelic.com/graphql` for Japan | | **Auth header** | `API-Key: ` | | **Queries** | NRQL `SELECT` statements against `NrMTDConsumption`, `NrConsumption`, and `NrDailyUsage` | | **Accounts** | Only those you grant the integration user | | **Mutations** | None. OneLens issues no NerdGraph mutations of any kind | ## What OneLens Will NOT Access * ❌ **Your telemetry.** No APM traces, no logs, no browser or mobile events, no infrastructure metrics, no custom events. See the honest caveat above: this is our commitment and our audit log, not a technical restriction New Relic provides * ❌ **Dashboards, alerts, or workflows.** OneLens does not read or modify them * ❌ **NerdGraph mutations.** No user creation, no configuration change, no data deletion * ❌ **Accounts you did not grant.** The integration user reaches only the accounts you assign it * ❌ **Your invoices, payment method, or contract documents** * ❌ **License, Ingest, Browser, or Mobile keys.** OneLens needs none of them and will refuse them if offered ## Prerequisites * A New Relic account on a **paid plan**. The free tier has no billable consumption to report. * Permission to **create a user** in your New Relic organization and assign account access. * Access to **Administration → Usage Summary**, to sanity-check what OneLens reports against what New Relic shows you. * Your **New Relic contract or order form**, for the rate card in step 4. This is usually the slowest part, so start it early. * `curl` and `jq` on the machine you run the validation calls from. ## Validate and Connect {% stepper %} {% step %} ### Create a Dedicated Integration User Do not use your own account. New Relic makes the case for a dedicated user directly: "A big advantage of this is that you don't need to use your Admin-level access for the integration," and "all you have to do is create the new user and assign only the accounts that you want to expose to the integration." 1. In New Relic, go to **Administration → User management**. 2. Add a user with a traceable name, such as `onelens-cost-integration`, on an address your team controls rather than a personal mailbox. A shared alias or group address works well, since the key deactivates if the user is deleted. 3. Set the user type to **Basic**. Basic users are free and can still run every query this integration needs, because New Relic grants all users the ability to "query all data in the accounts they can access." 4. Grant account access deliberately. **Assign the parent account** if your organization uses a parent-child structure and you want usage for all sub-accounts, and add individual accounts only where you need them. Account assignment is your main exposure control, so treat it as the security decision it is. 5. **If your sensitive data is in logs and you are on Pro or Enterprise**, also apply a [Data access control](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/data-access-control/) policy to this user. It restricts which log partitions a user can read, it binds user keys, and it is the one within-account restriction New Relic offers. It does not cover metrics, traces, or events. {% hint style="info" %} **Why the parent account, and when it applies.** Usage events carry a `consumingAccountId`, and New Relic's guidance is that if you have a parent account structure, you should "run queries in a parent account to see the aggregated usage for that parent and its child accounts." So on a parent-child organization, one grant gives full cost coverage while keeping readable telemetry to a single account, usually the one holding the least. This depends on your organization actually having that structure. Not every New Relic organization does, and the guidance is filed under New Relic's original account structure. The first query in the next step verifies it for your setup before you rely on it. If it comes back with only the parent, grant the accounts you need individually instead. {% endhint %} {% endstep %} {% step %} ### Create the User Key Do this **while signed in as the integration user**, or create the key on that user's behalf as an admin. A key created under your own login inherits your access, not the integration user's, which defeats the previous step. 1. Open the **API keys** page from the user menu, or go straight to `one.newrelic.com/api-keys`. It is not nested under Administration. 2. Select **Create a key**, and choose **User key**. 3. Set the account and give it a name such as `onelens-cost-integration`. 4. Copy the key immediately. It begins with `NRAK-`. Confirm the key belongs to the user you intended, which is the single most common setup mistake here: ```bash export NR_USER_KEY="NRAK-your_key_here" export NR_REGION_URL="https://api.newrelic.com/graphql" # api.eu. or api.jp. for those regions curl -s "$NR_REGION_URL" \ -H "API-Key: $NR_USER_KEY" \ -H 'Content-Type: application/json' \ --data '{"query":"{ actor { user { name email } } }"}' | jq ``` The name and email that come back must be the integration user. If they are yours, the key was created under your login and you should delete it and try again. Now list what the key can actually reach: ```bash curl -s "$NR_REGION_URL" \ -H "API-Key: $NR_USER_KEY" \ -H 'Content-Type: application/json' \ --data '{"query":"{ actor { accounts { id name } } }"}' | jq -r '.data.actor.accounts[] | "\(.id)\t\(.name)"' ``` Check this list against what you intended to grant. Anything unexpected on it is readable by this key, so fix the user's account access now rather than later. {% endstep %} {% step %} ### Validate the Usage Data Three queries. The first proves cost data exists, the second proves sub-account attribution works, the third proves you can separate data cost from seat cost. Set your parent account ID first: ```bash export NR_ACCOUNT_ID="your_numeric_account_id" ``` #### A. Ingest by consuming account This is the query that confirms the parent-account approach covers your children. It uses `NrConsumption`, which is the event New Relic documents `consumingAccountId` against: ```bash NRQL='SELECT sum(GigabytesIngested) FROM NrConsumption FACET consumingAccountId SINCE 2 months ago' curl -s "$NR_REGION_URL" \ -H "API-Key: $NR_USER_KEY" \ -H 'Content-Type: application/json' \ --data "$(jq -n --arg nrql "$NRQL" --arg acct "$NR_ACCOUNT_ID" \ '{query: "{ actor { account(id: \($acct)) { nrql(query: \"\($nrql)\") { results } } } }"}')" \ | jq '.data.actor.account.nrql.results' ``` You should get one row per consuming account. If you only get the parent, your sub-accounts are not visible from here and you will need to grant the integration user access to them individually. #### B. Billable totals These are the quantities your invoice is built on. New Relic documents `latest()` rather than `sum()` for month-to-date attributes, since they are running aggregates: ```bash NRQL='SELECT latest(GigabytesIngestedBillable), latest(FullPlatformUsersBillable), latest(CoreUsersBillable) FROM NrMTDConsumption SINCE 1 month ago' curl -s "$NR_REGION_URL" \ -H "API-Key: $NR_USER_KEY" \ -H 'Content-Type: application/json' \ --data "$(jq -n --arg nrql "$NRQL" --arg acct "$NR_ACCOUNT_ID" \ '{query: "{ actor { account(id: \($acct)) { nrql(query: \"\($nrql)\") { results } } } }"}')" \ | jq '.data.actor.account.nrql.results' ``` #### C. Ingest by product line This confirms consumption is attributable to the right categories: ```bash NRQL='SELECT sum(GigabytesIngested) FROM NrConsumption FACET productLine SINCE 1 month ago' curl -s "$NR_REGION_URL" \ -H "API-Key: $NR_USER_KEY" \ -H 'Content-Type: application/json' \ --data "$(jq -n --arg nrql "$NRQL" --arg acct "$NR_ACCOUNT_ID" \ '{query: "{ actor { account(id: \($acct)) { nrql(query: \"\($nrql)\") { results } } } }"}')" \ | jq '.data.actor.account.nrql.results' ``` **What to check:** | Check | What good looks like | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No `errors` key in the response | An `errors` block usually means the key lacks access to that account ID | | Query A returns multiple accounts | Confirms sub-account attribution works from the parent. One row means it does not, or that your organization does not use a parent-child structure | | Billable GB is non-zero | Zero across a full month usually means your consumption sat inside the free allowance, so there is no data cost to report yet. Seat cost may still be non-zero | | User counts look right | Compare against **Administration → Usage Summary**. They should agree | | `productLine` values appear | Expect values such as `DataPlatform`, `FullStackObservability`, and `ProactiveDetection` | {% hint style="warning" %} **Cross-check before you move on.** Open **Administration → Usage Summary** in New Relic and compare its figures to what these queries returned. If they disagree, resolve that now. Every cost number OneLens produces is built on these quantities, so an error here propagates into everything downstream. {% endhint %} {% endstep %} {% step %} ### Gather Your Rate Card This is the step that decides whether your OneLens New Relic cost matches your invoice, and it is the one that usually takes longest, because the numbers live in a contract rather than a UI. New Relic's own surfaces will tell you which pricing model you are on. **Administration → Usage Summary** shows what you consume, and **Administration → Consumption Management** shows how it is being counted. The *rates* are not in the product at all, so the numbers below come from your order form, contract, or your New Relic account team. Collect: | Item | Why it is needed | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | Pricing model | Data + User, Data + Core Compute, or Advanced Compute. This determines what OneLens prices at all | | Subscription term start and end date | Anchors commitments and lets OneLens apply the right rates to the right period | | Per-GB ingest rate | The main data cost driver. Note separately if you are on Data Plus, which is priced differently from Original Data | | Free ingest allowance | 100 GB per month is standard, but confirm yours, since negotiated agreements vary | | Per-user rates | Separate rates for Full Platform and Core users. Basic is free | | Free user seats | Many contracts include a number of Full Platform seats before per-seat charges begin | | Synthetic check pricing | Priced per check on many contracts, and reported separately in `NrDailyUsage` | | Tiered or volume pricing | If your per-GB rate steps down above a threshold, give us the tiers rather than a blended average, or the model will be wrong at both ends | | Committed volume or spend | So OneLens can show consumption against commitment rather than just raw spend | | Currency | Your invoicing currency | {% hint style="warning" %} **Tell us when your contract changes.** OneLens carries the rates you give us until you say otherwise. A renewal at new rates, with no word from you, produces cost figures that look plausible and are wrong. When your agreement changes, send us the new rate card and the effective date, and we will restate the affected periods rather than leaving a silent discontinuity in your history. {% endhint %} {% endstep %} {% step %} ### Connect to OneLens Provide the following, either through the OneLens dashboard or by emailing . | Field | Value | Example | | ----------------- | ----------------------------------------------------------- | ---------------- | | User key | The `NRAK-` key from step 2. Share securely, see note below | `NRAK-...` | | Parent Account ID | The numeric account ID you validated against | `1234567` | | Region | US, EU, or Japan, which decides the endpoint | `US` | | Rate card | Everything from step 4 | See step 4 table | {% hint style="danger" %} **Share the key securely.** Never send a `NRAK-` key over email or chat. Use a validated secure sharing tool such as [Password.link](https://password.link/en). {% endhint %} **What OneLens does next:** 1. Confirms the key resolves to the integration user, not a person, and tells you if it does not. 2. Lists the accounts the key can reach and sends you that list. **Check it.** It is both your coverage confirmation and your exposure confirmation. 3. Pulls the usage history New Relic still holds for your account and tells you the earliest period it actually received. 4. Applies your rate card and begins daily ingestion. **Verification.** Once OneLens confirms the connection, typically within 24 hours, check the OneLens dashboard for: * New Relic appearing as a cost source with a non-zero total for the last closed month * Data cost and seat cost shown separately, both non-zero if your contract has both * Every consuming account you expected, and none you did not * A total within a few percent of your last New Relic invoice. If it is out by more than that, the rate card is the first thing to re-check {% endstep %} {% endstepper %} ## Data Refresh Schedule * **Usage data** is pulled once daily. New Relic updates the usage UI daily, so a faster cadence returns the same numbers while consuming more CCUs on compute-based pricing. * **Month-to-date figures** move throughout the month as `NrMTDConsumption` accumulates. Treat the current month as provisional until the billing period closes. * **Rate card** changes only when you tell us. There is no API to detect a contract change, so this one depends on you. * **Account list** is re-read weekly, so a sub-account you grant later is picked up without a new key. New Relic bills users on the **highest user type assigned during the calendar month**, even if the assignment was brief. So a seat temporarily upgraded and downgraded still bills at the higher type, and OneLens reports it that way because New Relic charges it that way. ## Data Privacy & Security * **Usage events only.** OneLens queries `NrMTDConsumption`, `NrConsumption`, and `NrDailyUsage`, which hold consumption counters rather than telemetry. * **Read queries only.** No NerdGraph mutations, so nothing in New Relic can be created, changed, or deleted. * **Dedicated integration user.** Not tied to an employee, so no departure silently breaks or extends access. * **Exposure limited by account grant.** Your main control, and the reason step 1 matters more than it looks. * **Log partitions can be restricted further.** New Relic's Data access control binds user keys and can limit which log partitions the integration user reads, on Pro and Enterprise plans. * **A stated limitation, not a hidden one.** New Relic has no scoped keys, so our restriction to usage events is contractual and auditable rather than technically enforced. We keep an audit log of every query issued against your account and provide it on request. * **No agent, no ingest.** Nothing is installed, and OneLens sends no data into New Relic, so it adds no billable GB. * **Simple revocation.** Deleting the integration user deactivates its keys, and deleting a single key stops that credential alone. * **TLS in transit.** All calls use HTTPS/TLS 1.2+. * **Encrypted at rest.** The key and ingested data are encrypted at rest using GCP KMS. * **Data retention.** 12-month default, configurable. Deletion within 30 days on request, with confirmation. ## Troubleshooting | # | Symptom | Cause | Fix | | -- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | The `actor { user }` query returns your name, not the integration user's | The key was created while signed in as you, so it carries your permissions | Delete the key. Recreate it as the integration user, or as an admin acting on that user's behalf | | 2 | `errors` block saying the account is not accessible | The integration user has not been granted that account | Add the account to the user in **Administration → User management** | | 3 | Query A returns only the parent account | Either your organization does not use a parent-child account structure, or sub-account usage is not visible from the parent | Confirm your structure first. New Relic's guidance to run usage queries in a parent account applies to parent-child organizations. If yours is not one, grant the integration user access to each account you need and re-run query A | | 4 | Billable GB is zero for a full month | Your consumption sat inside the free allowance | Usually expected rather than an error. Cross-check against **Usage Summary**: if that page shows billable ingest and the query does not, tell us before connecting | | 5 | User counts disagree with Usage Summary | `NrMTDConsumption` reports month-to-date, and the UI may be showing a different window | Align the query window to the billing month. If they still differ, raise it with us before connecting | | 6 | `NrDailyUsage` figures do not match `NrMTDConsumption` | New Relic documents that `NrDailyUsage` results "may not match" the usage UI or `NrMTDConsumption` | Expected. OneLens treats `NrMTDConsumption` as authoritative and uses `NrDailyUsage` only for synthetics detail | | 7 | `429 Too Many Requests` | NerdGraph allows 25 concurrent requests **per user**, and the limit counts all keys belonging to that user together | Rare for us, since OneLens runs a few sequential queries. If you see it, something else is using the integration user's keys concurrently | | 8 | OneLens total does not match the invoice | Almost always the rate card: a tier we were not given, a changed contract, or a blended rate standing in for tiers | Re-check step 4 against your order form. Send us the corrected rates and the effective date and we will restate | | 9 | Cost history has a step change at a date nothing happened | A contract change we were not told about, applied to the whole history | Send us the old and new rates with the effective date so the periods are priced correctly | | 10 | Key stopped working | The integration user was deleted or deactivated, which deactivates its keys | Recreate the user and key. This is also the intended revocation path, so check whether someone removed it deliberately | | 11 | No per-service cost breakdown | New Relic's usage events carry no service or application dimension | Working as intended. Attribution below account level means structuring sub-accounts along your chargeback lines | ## Frequently Asked Questions
Can OneLens read our application data, logs, or traces? OneLens does not, and we will be precise about why rather than overclaim. What we do: issue NRQL read queries against `NrMTDConsumption`, `NrConsumption`, and `NrDailyUsage`. Those events hold consumption counters, not telemetry. We keep an audit log of every query issued against your account and provide it on request. What we cannot claim: that New Relic stops us. New Relic has no scoped API keys, so a User key able to read usage events in an account can also query telemetry in that same account. Our restriction is contractual and auditable, not technically enforced. If that distinction matters to your security team, there are two levers. Account access is the main one: grant the integration user only the accounts OneLens needs, and the technically-reachable surface shrinks to those. Second, if your sensitive data is in logs and you are on Pro or Enterprise, New Relic's Data access control can restrict which log partitions this user reads, and those policies do apply to user keys. It covers logs only, not metrics, traces, or events.
Why do we have to give you our pricing? Doesn't the API have costs? It used to, and New Relic removed it. The `estimatedCost` attribute on usage events was **deprecated in May 2022**, and the guidance since then is to query consumption quantities instead. No New Relic API returns your negotiated per-GB rate, per-user rates, committed volume, or tiered discounts, because those live in your contract rather than in the platform. Every cost platform that connects to New Relic asks for the same thing, for the same reason. What OneLens does differently is label the result clearly as rate-card derived, so nobody mistakes a modelled figure for an invoice line.
How accurate will the cost figures be? The quantities are exact. `GigabytesIngestedBillable` and the billable user counts are New Relic's own billing metrics, the same numbers behind your invoice. The rates are as accurate as what you give us. With a complete rate card, including tiers rather than a blended average, expect to land within a few percent of the invoice, with the remainder usually being mid-period changes or true-ups. It will be wrong if your contract changed and we were not told, if tiered rates were given as a single number, or if a commitment true-up lands outside the usage data. The first is the most common and the easiest to prevent: send us the new rate card and effective date whenever your agreement changes.
Does the integration user cost us a seat? No. Set it to **Basic**, which New Relic states is free, and it can still run every query this integration needs, because New Relic grants all users the ability to "query all data in the accounts they can access." One caveat if you are on Data + Core Compute or have the Advanced Compute add-on: those models are measured in Compute Capacity Units consumed by queries, alerts, API calls, and page loads, so our daily queries consume a small number. New Relic notes that free Basic users "can drive billing for usage-based features" this way. It is a handful of queries a day, and we will cut the cadence if you would rather.
Why a dedicated user instead of just using an admin's key? Because a New Relic User key is tied to the person who created it and inherits their access. Two consequences follow. An admin's key can reach everything that admin can reach, which is usually far more than a cost integration needs. And when that person changes role or leaves, New Relic deactivates their keys, so the integration breaks with no warning beyond a cost report going flat. A dedicated user fixes both, and New Relic makes the same case: "A big advantage of this is that you don't need to use your Admin-level access for the integration." The Basic user type is our recommendation rather than New Relic's. Their integration guidance does not name a user type; we suggest Basic because New Relic's user-type documentation confirms Basic users are free and can still query all data in accounts they can access. Use a shared team address rather than a personal mailbox, since the key stops working if the user is deleted.
Can we connect multiple New Relic accounts? Yes, and usually with one key. A User key can query any account its owning user has been granted, so granting the integration user your parent account is often enough to cover every sub-account, with usage attributed by `consumingAccountId`. Step 3's first query is what proves it for your structure. If it returns only the parent, grant the sub-accounts individually and re-run it. If your accounts sit in separate New Relic organizations, they need one integration user and key each.
Can we attribute New Relic cost to a team or service? Down to the account, yes, and that needs no work from you: New Relic stamps usage with `consumingAccountId`, and OneLens reports against it. You can group accounts into cost centres in OneLens on top of that. Below the account, no. The usage events carry no service or application dimension, so there is nothing to attribute from. Organizations that need service-level New Relic chargeback generally structure sub-accounts along the lines they want to charge back, because that is the boundary New Relic reports on. Worth knowing before you design a chargeback model around it.
Will this impact our New Relic performance or hit our limits? Performance, no. These are read queries against your usage events, nothing in your telemetry pipeline. Limits, effectively no. NerdGraph limits concurrency rather than request rate, at 25 concurrent requests per user, and OneLens runs a few sequential queries a day. Because the limit counts per user rather than per key, the dedicated integration user also means our queries never contend with your engineers' dashboards or your own automation.
What about the 100 GB free allowance? OneLens prices the `*Billable` attributes rather than raw consumed quantities, so free usage is not charged in your reported cost. Two practical notes. New Relic reports free and billable consumption as separate attributes on some usage events, so step 3's cross-check against your **Usage Summary** page exists to confirm the numbers agree before you rely on them. And confirm your own allowance in step 4, because 100 GB per month is the standard figure but negotiated agreements vary.
How do I rotate the key? Create a second User key under the same integration user, send it to OneLens securely, confirm ingestion continues on the next daily pull, then delete the old key on the **API keys** page. Overlapping them means no ingestion gap. Do not delete the integration user to rotate a key. That deactivates every key it owns at once and requires rebuilding the account grants.
How do I disconnect OneLens? Delete the User key on the **API keys** page, or delete the integration user, which deactivates all of its keys. Either way ingestion stops on the next attempted pull, and you do not need OneLens to act. Historical data already ingested remains in OneLens until you request deletion, which is completed within 30 days with confirmation.
How far back can you backfill? As far as New Relic still holds the usage events for your account. New Relic does not publish a retention period for its internal usage events, so rather than promise a number, OneLens pulls whatever history is available and tells you the earliest period it actually received. From connection onward, OneLens persists every daily pull, so your history grows forward regardless of how deep the initial backfill reached.
## Need Help? **New Relic official docs:** * [How New Relic pricing works, covering the pricing models and billable components](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/) * [Query and alert on usage data, the reference for the usage events and their attributes](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts/) * [Usage UI, for cross-checking what OneLens reports](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-ui/) * [Best practices for integration users](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/best-practices-integration/) * [New Relic API keys, on key types and what User keys carry](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) * [User type: basic, core, and full platform users](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/) * [User count and billing, on the highest-user-type rule](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing/) * [Data access control, for restricting log partition access](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/data-access-control/) * [Introduction to NerdGraph, including regional endpoints](https://docs.newrelic.com/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph/) * [NerdGraph usage limits](https://docs.newrelic.com/docs/apis/nerdgraph/nerdgraph-usage-limits/) * [Data ingest billing, on GB ingested and the free allowance](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing/) **OneLens support:** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.onelens.cloud/integrations/cloud-and-cost-sources/connecting-to-newrelic.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.