Skip to content

New Relic

Follow a failed request through your app’s server, group repeated errors and see which parts of the app slowed down.

Visit New Relic

How does New Relic help you investigate a failed booking?

New Relic can group the errors your server reports and show what happened during a particular request. When the booking page says “Something went wrong,” start with the server operation that saves a booking.

The part of New Relic that monitors how your app’s code runs is called application performance monitoring, or APM. Open the reporting service that handled the booking. In its APM errors inbox, a group combines reports of a similar error. Open a specific occurrence near the time the problem happened. Its stack trace can show which functions were running when the error occurred. Any connected logs can add details about what happened just before it.

Use the error group to find a pattern, then check the occurrence for the request you care about. A slow database step can be a lead. The records your app collected determine how far you can follow it.

What has to be connected before an error appears?

Connect the part of the app that actually saves the booking. A server-side monitoring library, called an APM agent, must support that runtime or the app needs separate reporting for the operation.

Start with the one test service your app uses to save bookings. Before it sends anything, confirm that the reporting account and app connections are disposable and that the message and captured fields contain no names, emails, passwords or booking details. Check whether the agent forwards logs automatically. Turn that forwarding off for the test if you have only approved error reports.

A failure handled inside your app can need an explicit error report. Some agents let you mark ordinary failures as expected so they remain visible without changing the error rate. For example, a customer trying to take an already reserved time is different from the database suddenly being unavailable.

New Relic’s APM errors inbox guide flags an EU-region restriction. Confirm the inbox is available in your account’s region before choosing this workflow.

What would you look for in one failed attempt?

Use a fictional booking to decide what evidence would let you find one failure and tell whether the fix worked. This is a paper exercise.

  1. Write down the attempt
    Imagine test booking B-17 failed at 10:04 after you clicked Reserve. Write the time, the action and the test service you expected to handle it.
  2. Pick the clue
    Imagine an occurrence in the booking service says “Could not save booking” at 10:04. Another occurrence in the same group is from yesterday. Pick today’s one and write down the operation you would inspect.
  3. Decide how you would verify the fix
    In a disposable setup, the same kind of new attempt should show a confirmation and one saved booking. The test should also tell you whether reporting still works. A blank inbox can mean the error stopped or that reports stopped arriving.

What uses the allowance, and how long can you look back?

The hosted Free edition lists 100 GB of incoming data per month and one Full Platform user. Incoming logs, errors and measurements can contribute to the same data allowance. If you exceed that limit on Free, New Relic stops accepting new data and blocks platform access until you upgrade to a paid edition or the next month begins.

On paid user-based plans, billable access and data volume are separate. Check the access type each teammate needs before inviting them. A Basic user can run queries but lacks the full APM interface. New Relic also offers a separate compute-based billing option on eligible editions. Use the account’s own plan when estimating costs.

History depends on the kind of data and your account settings. In Data retention, check the history for the individual error or log detail you need. Before increasing how much you send, decide how far back you actually need to investigate.

What evidence can you take with you?

A dashboard table can be downloaded as a CSV file. Use a table that selects the service, time window and safe fields you need for an incident handoff.

Keep the table’s time range, time zone and search conditions alongside the file. The download captures the table results, so keep your app’s own records and any other evidence you need separately. Check the file for private data before sharing it.