For consistency across New Relic content, here are our general word usage guidelines:
- We generally follow the Microsoft Style Guide, which is based on the Chicago Manual of Style.
- We follow American English conventions, rather than British English ones.
- We defer to the official product names for references to products. (For example, for Amazon Web Services (AWS), see aws.amazon.com/products.)
- For terminology specific to New Relic, we use the product glossary.
For the definition of agent, see the glossary.
- Don't capitalize: use
the Ruby agent, not
the Ruby Agent.
- Don't refer to a synthetics
private minionas an
integrationis a connection between technologies. New Relic provides many types of integrations, which are linkages between various technologies and our platform. And some of those integrations require no additional software: for example, some of our integrations just require changing a setting in a service to send data to New Relic, or changing an endpoint to send data to New Relic. Agents, on the other hand, are pieces of software that enable one or more integrations. For example, our APM agents have integrations with various app frameworks and web servers and types of databases. One way to frame this is: "The integrations included with our agents are just some of our many integrations" or "Our agent-based integrations..."
Use the 12-hour clock followed by the (lowercased) time period am or pm.
Don’t put a space after the last number in a timestamp (12:00am, not 12:00 am).
Don't include a leading 0 when the hour is less than 10.9:30am, 12:30pm, 8:30pm
Refer to the specific product, not just
- As a courtesy to your readers, on first mention always refer to Amazon products by their full names; for example Amazon Web Services (AWS). You can use the acronym after that, if there is one. Example:
Amazon Elastic Compute Cloud.
- After that, use the short name according to the AWS Documentation site. Example:
The "machine name" that the collector uses to uniquely identify an app is its
app name. The server-side configuration setting that changes the visible "name" of an app without changing its unique identifier is its
Use the beta callout. In the body text, use lowercase. For example:
This feature is currently in beta.
If the developer team prefers to use a term other than beta or private beta, clarify what is driving that use of the term (Legal requirement?), and add any relevant info here in the usage dictionary.
Use standard prefixes and capitalization for International System of Units (SI), International Organization for Standardization (ISO), or Joint Electron Device Engineering Council (JEDEC memory) values when referring to multiples of bits (b) and bytes (B). 1 byte = 8 bits.
For help with converting byte values (such as bytes to kilobytes), try this byte converter.
Don't use. Instead, use
deny list and
allow list; for example, "Add a hostname to your deny list."
When describing how one entity communicates or is connected to another, focus on the calls and which direction they’re going. For example, “service A calls service B,” “called services,” “calling services.”
Avoid using "upstream" and "downstream" to describe this.
A parent account contains one or more child accounts. Child accounts were previously referred to as "sub-accounts".
In general, use
click rather than the vaguer
select. For example, you might click something in the UI, but then select something from a list.
Be particularly careful to use
click to describe actions that only make sense with a mouse; for example, with a
right click or a
click and drag. Also use
click when the user must click on a non-selectable object (
to save your changes, click anywhere outside the dialog box). See also [mouse over]#mouse-over).
When referring to an agent talking to the New Relic servers, describe this as the New Relic collector. Although internally the
collector refers only to specific parts of our architecture, we use it more broadly in our documentation to mean "any endpoint a customer must connect to report data, for any product." Avoid "connect to New Relic," and do not use "connect to the New Relic UI."
When it makes sense for clarity, conciseness, and tone and voice, use contractions. Use them where they make the writing sound more like natural speech, and where they improve clarity and accessibility without sacrificing expertise and authority.
There are no hard and fast rules for which contractions are or aren't acceptable, but simple and common is preferable to complicated and rare. For example,
it is is fine, but less common constructions like
wouldn't've are best avoided.
- When using a negative contraction (
won't) try to provide some additional info about what what to do and what can be done. (See the style guide intro for more on this.)
- There are places in our docs—for example, in notes and warnings—where spelling out
will notis preferable to contractions to emphasize the action or blockage to be avoided.
When possible, use the second person
you to form a sense of connection with the reader. For times when you need a descriptive third-person noun, keep the following guidelines in mind:
userare both appropriate depending on context.
customermakes more sense when talking about billing, or about a group of people or a business entity. For example, one customer may have one or more individual users who interact with New Relic through the customer's account(s).
usermakes more sense as a general term for an individual user, or when talking about users as an object in the account model. For example, when discussing account models, it's important to be specific about what constitutes a single person identity in our system.
If you need to refer to the docs themselves—don't. Generally it's better to directly link to the doc you're referencing and use the doc title as your link text. For example,
See [Install the .NET agent](URL) rather than
See our [.NET agent install docs](URL).
If there's not a good alternative,
doc generally sounds more natural than
documentation. If you're tempted to use a longer form, try reading it aloud to see which reads best.
If you must refer to the site as a whole, call it the
docs site rather than
Docs site or
documentation site. Internally, you can also refer to the whole URL
docs.newrelic.com to avoid ambiguity with other sources of docs like internal platform docs or API explorer docs. To refer to our docs GitHub repo, use the repo name
docs-website or the repo path
Don't use to describe how entities relate to each other. How people interpret downstream and upstream varies significantly, so focus on the specific type of connection as we do in the related entities element: calls, creates, hosts, maintains, etc.
[Service A] calls [service B]
maintained by [repository name]
dropdown instead of
Although it isn't common usage, you can use
dropdown independently as a noun, without needing to say
dropdown menu or
dropdown list. For example,
select a date from the <b>date</b> dropdown.
Avoid these Latin abbreviations.
for example or
such as. Subbing for
i.e. is tricker, because sometimes people use it to mean
that is, while at other times it's mis-used to mean
for example. Read the context to be clear, but usually the best solution is to rewrite so the description is clear without needing explanatory text.
Em dashes are rarely needed in tech docs, sadly. You can usually accomplish what you need to by breaking the thought into multiple sentences or using parentheses. In some rare cases, though, an em dash can add drama and spice.
If you think you've found such a case, make sure you use them right. An em dash should always use the real em dash character (not a hyphen), and no space before and after. For example:
You can sign up for New Relic fast and free—we won't even ask for a credit card number.
You can insert an em dash with the
COMMAND+OPTION+- shortcut or use the HTML entity.
To understand how to optimally write about events, we recommend reading:
Some language-related considerations when writing about events:
It's important to understand some of the ambiguity and history around how we sometimes use the word "event." Prior to the roll-out of our three other core data types of
Span, at New Relic we referred to all NRDB-stored objects as "events." For this reason, internally and sometimes externally we still sometimes refer to all NRDB objects as "events." (For example, in the query UI, we still use "events inspected" and this refers to all NRDB data types). But for public-facing resources, we should attempt to use "event" to refer to NRDB-stored data that is not
It's important to understand how the concept of "event" can overlap with the concept of "metric." Both are broad general terms and due to that there can be some overlap in meaning. Because metrics are just measurements, all New Relic data (events, spans, logs) can be said to be or contain metrics. For example, the events reported by our infrastructure monitoring contain various metrics, which are simply numeric measurements of various kinds (read more about infrastructure events containing metrics).
This is one word. Don't hyphenate.
When using an inline icon from the UI, always describe it first, then embed the icon image, and then end with the word
select the delete
Don't put icons in bold.
When writing about icons, describe the icon for its purpose or action, not what the icon looks like. For example:
Avoid using generically, to avoid confusion with infrastructure monitoring.
Instead, use an appropriate substitute such as
Introduction to for overview docs for a particular product. For example,
Introduction to New Relic Infrastructure or
Introduction to the PHP agent or
Introduction to transaction traces.
Also avoid the
Thing: Tagline format, as in
X-Ray sessions: Traces and thread profiles for key transactions, unless having a title with keywords will help with SEO.
The proper name for Apple's desktop operating system is
Don't use the older product names
Mac OS X, or
Avoid and/or replace the use of "master" whenever possible. For example, use "main" for root branches in GitHub instead.
For an explanation of how the word "metric" is used in the industry and how it's used at New Relic, see Data types.
Some tips about some often confusing aspects of metric data:
Note that the word "metrics" is a broad, general concept and at New Relic we have a number of data types and data-reporting methods that are called "metrics".
The best metric data format is dimensional metric data, aka the
Metricdata type. That data is reported via the Metric API. This is the "metric" data that we are primarily referring to when we talk about the "metrics" in our four core "MELT" data types: metrics, events, logs, and traces.
Our original metric data format is called metric timeslice data. This is still reported by APM, browser monitoring, and mobile monitoring. This was a very simple form of metric data and was not stored in NRDB, so it could not be queried in NRQL. Currently APM metric timeslice data is mirrored in NRDB and so can be queried via NRQL.
Some style-related recommendations:
Err on the side of talking about "metrics" generally and not going into detail about the data structure and reporting process. In general, whether talking about dimensional metrics (the
Metricdata type) or metric timeslice data or metrics reported as infrastructure event attributes, you can simply use "metrics" or "metric data." It's thought that in most cases in docs and UI, a customer won't often need to know exactly what type of data it is. But if it's thought that it would be helpful to know the type of data (for example, when talking about how to query that data), you can give more detail about the type of data.
When you want to clarify the type of metric data in a simple way, you can link to a specific metric data type collapser in this section. For example, you might do something like this: "This integration reports metric data."
For mouse movements that involve placing the mouse pointer over an area, but not clicking it. For example, the APM Overview page includes functions that are only visible when the mouse pointer is over a particular chart. Do not use
point to or
hover over. See also
Always refer to the agent and language as
.NET, never as
Always refer to the programming language as
NR ONLY for internal consumption only (such as this style guide). Don't use
New Relic Only.
Use lower case for
open source. Some legal contracts may require upper case.
Use instead of "legacy" to refer to the first or previous versions of products, features, and capabilities that might still be in use. "Original" conveys the viability and ongoing support of the feature, while the word "legacy" can erroneously convey that a feature is no longer supported.
New Relic organizations can have a parent/child account structure. This is more important for our original user model but still plays a role for some behind-the-scenes features on our newer user model. Learn more about account structure.
Parent accounts were previously referred to as master accounts, and there are still some uses of this in the codebase.
Don't use this outside of browser monitoring docs. Often abbreviated as RUM, this is a generic industry term for browser monitoring. New Relic refers to this as
page load timing or
browser monitoring. Use this term only for SEO or clarification, not to refer to the actual feature.
report when discussing data sent to New Relic, such as, "your host reports data to New Relic."
Avoid using report as a noun. Instead use "the reported metrics" or "the collected data."
If "report" sounds too clunky, you can also use
collect as long as whatever New Relic is collecting doesn't sound security sensitive.
Don't refer to the New Relic UI as
RPM. Always refer to the specific product, such as the
APM UI or the
Browser UI. However, you may use
rpm when required in the visible URL string in UI paths.
Also referred to as an Oxford comma. Always use serial commas with inline lists. For example,
Portland, Seattle, and Dublin rather than
Portland, Seattle and Dublin.
Include a space (time zone). Don't hyphenate or run together as timezone.
update when users need to change the version of whatever they're using. No money or payment is needed for an update.
upgrade whenever money or payment may be involved, such as upgrading to the Pro version of a product. The new pricing model makes it unlikely that you'll need to use this.
One word (
username), not two. This is the most common usage and is recommended by Microsoft and Google style guides.
When referring to multiple version numbers, use
or higher or
or lower. Don't use
and higher (it's more ambiguous than
or), or the words
later. Also don't use punctuation, as in
version 1.2+ or
<version 1.2. For example:
Foo requires Ruby agent version 1.2.3 or higher
Bar is compatible with ActiveMerchant version 4.5.6 or lower
You'll find that both
versions work depending on the context; try reading it aloud if you're unsure.
Other usage notes:
- Tell users to use the
latest versionand not an
- To abbreviate the word
version, use a lowercase
vwith no space before the number; for example,
upgradewhen talking about agent versions, as in "To update to the latest version..."
- For security reasons, do not use version numbers with licensing docs.
- Consider using
in earlier agent versionswhen referring to versions more vaguely.
our when it works with the flow of your writing. Avoid overloading paragraphs with
New Relic mentions, or reword so the focus is on the user, not New Relic. For example, avoid writing something like this:
New Relic recommends setting a startup timeout.
Instead, write something like this:
Recommendation: To help with troubleshooting, include a startup timeout in your configuration.
We recommend setting a startup timeout.
your liberally in our docs. Addressing the reader directly makes for simpler, cleaner sentences. It also tends to expose lazy uses of passive construction and it helps users to understand procedures.