1. TL;DR

New Relic Change Tracking puts deploy and configuration markers on service timelines. Anyshift finds which production services a shared change actually affects, then prepares one reviewed New Relic event per service.

In the demo below, one Redis rollout becomes three Change Tracking events under the same groupId. Anyshift maps the shared change to the affected production services, so checkout, notifications, and catalog each see the rollout on the New Relic timeline they already use.

Three-step workflow showing a shared Redis change, the Anyshift production graph identifying checkout, notifications, and catalog, and one reviewed New Relic Change Tracking event appearing on each service timeline.

2. How New Relic tracks changes

New Relic is where teams investigate slow requests, errors, and availability problems. A New Relic entity is a monitored service (for example, checkout-service, notification-worker, or catalog-api). A Change Tracking event adds a marker to that service's charts and Change tracking page.

The New Relic CLI creates those events. It needs the target entity, plus details such as the change's version, commit, source link, and a groupId (the same rollout can then be found across several entities).

3. Why shared changes are harder

For a normal application deploy, the deploy system knows which service it shipped. Shared changes are harder. A cache upgrade, IAM policy update, queue setting, or Terraform module can affect services that did not deploy. Someone has to identify them before New Relic can mark their timelines (this is where production topology becomes genuinely useful).

A platform team upgrades session-cache from Redis 7.0 to Redis 7.2. The deploy pipeline knows the cache changed. It does not know that checkout, notifications, and catalog all use it in production.

Redis 7.2 rollout
  checkout-service        payments
  notification-worker     notifications
  catalog-api             catalog

If checkout latency rises after the rollout, the checkout team will open the checkout-service entity in New Relic. The same rollout should also appear on the notifications and catalog timelines: one shared change, three useful markers ;) Nobody should have to reconstruct that dependency from code and ownership records while reading a latency chart.

4. How Anyshift adds production context

This is the boundary for the workflow: Anyshift decides where each marker belongs and records the evidence. The New Relic CLI performs the write with the engineer's authentication.

Anyshift via annie do     finds affected production services and the reason each is included
New Relic CLI             creates one native Change Tracking event for each matching entity

New Relic remains where teams investigate. Anyshift's annie do workflow selects the entities, shows why each one was included, and hands the approved commands to the New Relic CLI. I like this boundary: New Relic stays the operational surface, while Anyshift handles the graph question upstream.

For the Redis rollout, annie do looks up facts that usually live in different places (and are annoying to join by hand):

  • Dependencies: checkout, notifications, and catalog read session-cache, even though only the cache changed.
  • Runtime: sandbox and deprecated workloads are skipped (good, because a large target list is not automatically a correct one).
  • Ownership: checkout maps to payments, the worker to notifications, and the catalog API to catalog.
  • New Relic target and evidence: each service maps to an entity, with a short reason such as "reads session-cache on cart paths."

The output is deliberately specific. It gives the CLI an entity to update and gives the engineer a reason to trust that choice.

5. Review before New Relic writes

annie do looks up the affected services, prepares the New Relic commands, and stops for review. The final write stays with newrelic, New Relic's CLI, using the engineer's authentication (no second credential path to manage).

annie do renders the handoff in Go, with a deterministic shell loop and New Relic payload. The engineer sees every generated step before anything is sent. After approval, the New Relic CLI runs the commands and saves the audit file on disk.

The terminal below is the review surface. The full runbook stays on disk and keeps the target services, the New Relic command, and the shared groupId together (compact enough to review, complete enough to audit).

Raw terminal view of the annie do New Relic runbook opened in Vim, showing three selected entities, their owners and dependency evidence, plus generated true and executed false.

The shared groupId ties the events together as one change set, while each service keeps its own event. Small detail, but a useful one :)

The terminal above is a dry run. It generates the runbook but does not execute it (nothing has reached New Relic yet). The before-and-after screenshots below come from a separate demo execution after approval.

6. Results in New Relic

Before the run, the checkout workload has no recent Change Tracking event for the Redis rollout.

Cropped New Relic Change Tracking table for checkout-service-prod before the run, showing Change events 0 and an empty event table.

After approval, the New Relic CLI writes the event to that workload (same demo tenant, same entity).

Cropped New Relic Change Tracking table for checkout-service-prod after the run, showing Change events 1 with redis-7.2.5, the rollout description, and annie as the user.

The same run writes events for notification-worker-prod and catalog-api-prod, recording all three IDs under the same groupId. That is the cool part: each team gets local context without losing the shared rollout (!)

A deploy pipeline can mark the service it just shipped, which is usually enough. A shared change can affect services that did not deploy, leaving their New Relic charts without the change. annie do identifies those services, maps them to New Relic entities, and prepares one reviewed event per entity (including the evidence for why it belongs there).

After approval, checkout, notifications, and catalog each see the Redis rollout on their own timeline. The events share a source link and groupId, and each carries the reason that service was included. When a team opens New Relic during an incident, the relevant change is already on the chart (which is exactly where it should be).

7. What's next

Pre-change preview. annie do can show the entities and owning teams before a risky rollout.

Post-change correlation. It can attach the dependency evidence when latency or errors move after an event.

Change-set reporting. Teams can query the rollout across entities through its shared groupId.

If your team uses New Relic and wants to test this on a shared infrastructure change, contact us.