Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fapm-v2%2Fuse-cases.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fapm-v2%2Fuse-cases.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# Use cases

APM v2 answers a different question depending on what you are doing and who you are. Find your task in [Common scenarios](#common-scenarios), follow a [walkthrough](#walkthroughs), or jump to your role below. Each entry links to the feature behind it.

## Common scenarios[​](#common-scenarios "Direct link to Common scenarios")

* **Trace a request end to end**: follow a request across services in the [Traces tab](https://coralogix.com/docs/user-guides/apm-v2/features/traces.md), see the topology in the [Service Map](https://coralogix.com/docs/user-guides/apm-v2/features/service-map.md), and inspect upstream and downstream calls in [Dependencies](https://coralogix.com/docs/user-guides/apm-v2/features/dependencies.md).
* **Diagnose a latency spike**: read the RED charts on the entity [Overview](https://coralogix.com/docs/user-guides/apm-v2/entity-drilldown.md), find the slow route in [Transactions](https://coralogix.com/docs/user-guides/apm-v2/features/transactions.md), and rule out the runtime or host in the [Runtime](https://coralogix.com/docs/user-guides/apm-v2/features/runtime-metrics.md) and [Infrastructure](https://coralogix.com/docs/user-guides/apm-v2/features/infrastructure.md) tabs.
* **Investigate an error surge**: group failures by status code in the [Errors tab](https://coralogix.com/docs/user-guides/apm-v2/features/errors.md), then pivot to the [Traces](https://coralogix.com/docs/user-guides/apm-v2/features/traces.md) and [Logs](https://coralogix.com/docs/user-guides/apm-v2/features/logs.md) behind them.
* **Monitor service health and SLOs**: track health across the fleet in the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md), and manage SLOs, alerts, and cases in the [Monitoring tab](https://coralogix.com/docs/user-guides/apm-v2/features/monitoring.md). See [service health](https://coralogix.com/docs/user-guides/apm-v2/features/service-health.md) and [Service SLOs](https://coralogix.com/docs/user-guides/apm-v2/features/service-slos.md).
* **Correlate a change with a regression**: overlay deployments and configuration changes with [annotations](https://coralogix.com/docs/user-guides/apm-v2/features/annotations.md), and [compare](https://coralogix.com/docs/user-guides/apm-v2/services.md#compare-to-a-previous-period) current performance against an earlier period.
* **Monitor database performance**: switch the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) to Databases to compare query volume, latency, and failures, then use a service's [Dependencies](https://coralogix.com/docs/user-guides/apm-v2/features/dependencies.md) to see which services drive the load.
* **Control span-metric cost**: keep cardinality in check with [cardinality limiting](https://coralogix.com/docs/user-guides/apm-v2/getting-started/span-metrics-cardinality-limits.md) and [sampling](https://coralogix.com/docs/user-guides/apm-v2/getting-started/span-metrics-recommended-configuration.md).

## Walkthroughs[​](#walkthroughs "Direct link to Walkthroughs")

These worked examples take a task from symptom to cause, naming the exact controls to use at each step.

### Diagnose a latency spike[​](#diagnose-a-latency-spike "Direct link to Diagnose a latency spike")

**You'll need:** a service reporting to APM v2, and a time range covering the spike. **Time:** about 5 minutes. **You'll end with:** the transaction, dependency, or host responsible, and the traces that prove it.

1. In the Coralogix toolbar, select **APM**, then open **Services**.
2. Sort by **P95 latency** and select the service that spiked. Its **Overview** tab opens on the RED cards.
3. On the **Latency** card, select **P95** and **P99** together. If P99 moved but P95 did not, this is a tail problem - a small share of slow requests - not a service-wide regression.
4. Set **Compare to** → **previous consecutive period**. Each card now shows a delta against the equivalent window, so you can tell a spike from normal daily shape.
5. Read the **Avg latency by dependency** card. If one backend dominates, skip to step 7.
6. Open **Transactions** and sort by **Time consuming**, not by latency - the transaction consuming the most total time is the one worth fixing. Open it to see its segments and spans.
7. Rule out the layers beneath the code: **Runtime** for GC pressure and thread contention on JVM services, **Infrastructure** for CPU, memory, and network pressure on its hosts.
8. Confirm it: open **Traces**, filter to the slow transaction, and open a trace from inside the spike. The longest span is your answer.
9. Find out what changed: turn on **Annotations** and look for a deployment or configuration change at the start of the spike.

If latency is high but no transaction stands out, the load is spread - check Infrastructure for a shared-resource limit before looking further into the code.

**Next:** set a latency threshold that catches this earlier - see [Service health](https://coralogix.com/docs/user-guides/apm-v2/features/service-health.md).

### Investigate an error surge[​](#investigate-an-error-surge "Direct link to Investigate an error surge")

**You'll need:** a service with a rising error rate, and a time range covering the surge. **Time:** about 5 minutes. **You'll end with:** the failing operation, the status code behind it, and the traces and logs that explain it.

1. In the Coralogix toolbar, select **APM**, then open **Services**.
2. Sort by **Error rate** and select the service that surged. Its **Overview** tab opens on the RED cards.
3. Set **Compare to** → **previous consecutive period** to separate a real surge from normal error noise.
4. Open the **Errors** tab. Failures group by status code for services (or by operation for databases) - open the largest group.
5. Read **Failing transactions** to see which requests carry the errors, and use the error-class filter (**Server errors** / **Client errors**) to tell a broken dependency from bad input.
6. Open an error occurrence to jump to its **span**, then its full **trace** - the failing span shows the exception and where it was thrown.
7. Pivot to the **Logs** tab for the log lines around the failure.
8. Find out what changed: turn on **Annotations** and look for a deployment at the start of the surge.

**Next:** turn the recurring failure into an alert from the [Monitoring](https://coralogix.com/docs/user-guides/apm-v2/features/monitoring.md) tab.

### Find the slow database behind a slow service[​](#find-the-slow-database-behind-a-slow-service "Direct link to Find the slow database behind a slow service")

**You'll need:** a service whose latency is driven by a backend, and a time range covering the slowdown. **Time:** about 5 minutes. **You'll end with:** the database operation responsible and the query spans that prove it.

1. From the slow service's **Overview** tab, read the **Avg latency by dependency** card - if a database dominates the time per request, that's your lead.
2. Open the service's **Dependencies** tab and switch to the **Databases** view. Rank by **Total time spent** to find the database the service waits on most.
3. Open that database's drilldown drawer and read its **Root transactions** breakdown to see which of the service's transactions drive the load.
4. Switch the catalog to **Databases** and open the database as an entity. Its **Operations** tab ranks operations by time consumed.
5. Open the slowest operation to inspect its query spans and the traces they belong to - the query text and duration are on the span.

**Next:** compare the database against an earlier period to confirm the regression, from the [Databases](https://coralogix.com/docs/user-guides/apm-v2/databases.md) catalog.

## For on-call responders[​](#for-on-call-responders "Direct link to For on-call responders")

You arrive mid-incident, usually from a page rather than the catalog, and need to get from alert to cause fast.

* **Start from the alert or case**: an entity's [Monitoring tab](https://coralogix.com/docs/user-guides/apm-v2/features/monitoring.md) shows the alerts and cases attached to it, and a firing alert has already opened a case.
* **Confirm the symptom**: the entity [Overview](https://coralogix.com/docs/user-guides/apm-v2/entity-drilldown.md) RED cards, with **Compare to** on, show whether latency or errors moved and by how much.
* **Find the cause**: follow [Diagnose a latency spike](#diagnose-a-latency-spike) or [Investigate an error surge](#investigate-an-error-surge) above.
* **Read the blast radius**: the [Service Map](https://coralogix.com/docs/user-guides/apm-v2/features/service-map.md) and [Dependencies](https://coralogix.com/docs/user-guides/apm-v2/features/dependencies.md) show everything upstream and downstream of the failing entity.
* **Line up the trigger**: [annotations](https://coralogix.com/docs/user-guides/apm-v2/features/annotations.md) overlay the deployment or change that started it.

## For application engineers[​](#for-application-engineers "Direct link to For application engineers")

You own a service and need to know why it is slow or failing, and where in the code to look.

* **Start at your service**: open it from the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) to see its [RED metrics and health](https://coralogix.com/docs/user-guides/apm-v2/entity-drilldown.md) at a glance.
* **Find the failing requests**: in the [Errors tab](https://coralogix.com/docs/user-guides/apm-v2/features/errors.md), group errors by status code, open the top group, and jump to the errored span.
* **Isolate the slow path**: in the [Transactions tab](https://coralogix.com/docs/user-guides/apm-v2/features/transactions.md), find the slowest route or operation and drill into its segments and spans.
* **See the request end to end**: pivot to the [Traces tab](https://coralogix.com/docs/user-guides/apm-v2/features/traces.md) for the full trace, and the [Logs tab](https://coralogix.com/docs/user-guides/apm-v2/features/logs.md) for the log lines around it.
* **Rule out the runtime**: for JVM services, the [Runtime tab](https://coralogix.com/docs/user-guides/apm-v2/features/runtime-metrics.md) surfaces memory leaks, GC pressure, and thread contention.
* **Check downstream**: the [Dependencies tab](https://coralogix.com/docs/user-guides/apm-v2/features/dependencies.md) shows whether a database or external call is the real cause.

## For DevOps and SRE[​](#for-devops-and-sre "Direct link to For DevOps and SRE")

You keep a fleet of services healthy, respond to incidents, and stop regressions before they reach users.

* **Scan fleet health**: the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) Health view and service health map show which services are critical, warning, healthy, or unmonitored. Filter by environment to focus on production.
* **Define reliability targets**: track SLOs and error budgets in the [Monitoring tab](https://coralogix.com/docs/user-guides/apm-v2/features/monitoring.md). See [Service SLOs](https://coralogix.com/docs/user-guides/apm-v2/features/service-slos.md).
* **Respond to issues**: alerts and cases attached to an entity live in the same [Monitoring tab](https://coralogix.com/docs/user-guides/apm-v2/features/monitoring.md); create alerts straight from a widget. See [APM monitoring with alerts](https://coralogix.com/docs/user-guides/apm-v2/features/monitoring-with-alerts.md).
* **Correlate with deployments**: [annotations](https://coralogix.com/docs/user-guides/apm-v2/features/annotations.md) overlay deployments and configuration changes on the charts so you can line up a spike with a release.
* **Separate infra from application problems**: the [Infrastructure tab](https://coralogix.com/docs/user-guides/apm-v2/features/infrastructure.md) shows CPU, memory, and network pressure on the hosts an entity runs on.
* **Understand blast radius**: the [Service Map](https://coralogix.com/docs/user-guides/apm-v2/features/service-map.md) and [Dependencies](https://coralogix.com/docs/user-guides/apm-v2/features/dependencies.md) show what a failing service affects.
* **Catch regressions**: compare current performance against a previous period from the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md#compare-to-a-previous-period).

## For engineering managers[​](#for-engineering-managers "Direct link to For engineering managers")

You track the reliability posture of your team's services and decide where to invest.

* **See ownership at a glance**: the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) Ownership view adds owner, alerts, cases, and SLO status columns. Filter by team to see only your services.
* **Watch SLO compliance**: [Service SLOs](https://coralogix.com/docs/user-guides/apm-v2/features/service-slos.md) and their error budgets show which services are meeting their targets and which are burning budget.
* **Spot chronic problems**: [service health](https://coralogix.com/docs/user-guides/apm-v2/features/service-health.md) trends surface the services that sit in warning or critical over time.
* **Measure user satisfaction**: the [Apdex score](https://coralogix.com/docs/user-guides/apm-v2/features/apdex-score.md) turns latency into a single satisfaction signal per service.

## For database engineers[​](#for-database-engineers "Direct link to For database engineers")

You monitor database performance and the services that put load on your databases.

* **Monitor databases as entities**: select **Databases** in the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) to compare query volume, latency, and failures per database.
* **Break performance down by operation**: a database's Operations tab in the [drilldown](https://coralogix.com/docs/user-guides/apm-v2/entity-drilldown.md) shows query throughput, latency, and errors per operation and table, plus how many services call each one.
* **Investigate database errors**: a database's [drilldown](https://coralogix.com/docs/user-guides/apm-v2/entity-drilldown.md) surfaces its error groups and recent traces.
* **Trace load back to its source**: a service's [Dependencies tab](https://coralogix.com/docs/user-guides/apm-v2/features/dependencies.md) shows which services query a database and how those queries perform.
* **See the topology**: the [Service Map](https://coralogix.com/docs/user-guides/apm-v2/features/service-map.md) shows how your services connect to their databases.

## Next steps[​](#next-steps "Direct link to Next steps")

Instrument your first service in the [APM onboarding tutorial](https://coralogix.com/docs/user-guides/apm-v2/getting-started/apm-onboarding-tutorial.md), then explore it in the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md).