• /
  • EnglishEspañolFrançais日本語한국어Português
  • EntrarComeçar agora

Level 2 - APM criticality tag coverage scorecard rule

APM criticality tag coverage ensures that your applications are properly labeled with business criticality levels, helping you prioritize monitoring efforts, incident response, and resource allocation based on business impact.

About this scorecard rule

This APM criticality tag coverage rule is part of Level 2 (Proactive) in the business uptime maturity model. It evaluates whether your APM applications have criticality tags that indicate their importance to business operations.

Why this matters: Criticality tags help teams understand which systems require immediate attention during incidents and which can tolerate longer resolution times. This enables more effective resource allocation and ensures critical business functions receive appropriate monitoring coverage.

Description

The score is based on the most recent entity scan and fails if the target entity does not have a value for their “criticality” tag.

Interpretation

A low score on this rule may indicate that your organization hasn't fully implemented metadata or semantic conventions for your systems estate. The criticality tag is crucial for improving organizational clarity within the observability platform, helping to distinguish between different operational contexts for mission critical, customer impacting, internal, or compliance business purposes. Having a standard for identification of business criticality will allow you to develop alerting, SLI, or ongoing improvement processes that focus attention and resources on the most important systems.

Understanding criticality levels

Establish a consistent criticality tagging strategy that aligns with your business priorities:

High criticality

  • Revenue-generating applications: E-commerce platforms, payment processing, billing systems
  • Customer-facing services: User authentication, core product features, customer support portals
  • Regulatory compliance systems: Financial reporting, data privacy, audit logging
  • Response expectation: Immediate attention (within minutes), 24/7 monitoring

Medium criticality

  • Supporting business functions: Internal tools, reporting systems, data analytics platforms
  • Non-customer-facing APIs: Internal integrations, data synchronization services
  • Development and testing infrastructure: CI/CD pipelines, staging environments
  • Response expectation: Business hours response (within 1-4 hours)

Low criticality

  • Experimental features: Beta functionality, A/B testing platforms
  • Internal utilities: Monitoring dashboards, administrative tools
  • Non-production environments: Development, sandbox, training systems
  • Response expectation: Planned maintenance windows, next business day

How to implement criticality tagging

Follow these steps to establish comprehensive criticality tag coverage:

1. Assess your application portfolio

  1. Inventory all APM applications: List every application currently monitored
  2. Evaluate business impact: Work with business stakeholders to understand each application's role
  3. Document dependencies: Identify how applications interact and support each other
  4. Classify by user impact: Determine which applications directly affect customers vs. internal users

2. Define your tagging schema

Choose consistent tag values:

  • Use standardized values: high, medium, low or critical, important, standard
  • Document the criteria for each level clearly
  • Ensure all teams understand and apply the same standards

Consider additional context tags:

  • Environment: production, staging, development
  • Business unit: payments, customer-service, marketing
  • Geographic region: us-east, eu-west, asia-pacific
  • Technology stack: frontend, backend, database, api

3. Implement tags systematically

Use automation where possible:

  • Agent configuration: Set tags through environment variables or configuration files
  • Deployment automation: Include tagging in your CI/CD pipeline
  • Infrastructure as code: Define tags in Terraform, CloudFormation, or similar tools
  • API automation: Use New Relic APIs to bulk-apply tags based on naming conventions

Manual tagging process:

  1. Start with high-criticality applications: Focus first on business-critical systems
  2. Work by team or domain: Assign tagging responsibility to application owners
  3. Validate and review: Ensure tags are applied correctly and consistently
  4. Regular maintenance: Schedule periodic reviews to update tags as applications evolve

Measuring improvement

Track these metrics to verify your criticality tagging improvements:

  • Tag coverage percentage: Aim for 100% criticality tag coverage across all APM applications
  • Tag accuracy: Ensure tags correctly reflect actual business criticality through periodic review
  • Response prioritization: Measure whether critical incidents receive faster response times
  • Resource allocation effectiveness: Verify that monitoring resources focus appropriately on critical systems

Common scenarios and solutions

Legacy applications with unclear criticality:

  • Problem: Older applications may not have clear business owners or documented importance
  • Solution: Start with conservative tagging (medium criticality) and refine based on incident impact analysis

Microservices with complex dependencies:

  • Problem: Individual services may seem low-criticality but support critical business functions
  • Solution: Use service mapping to understand dependencies and tag based on downstream impact

Development and testing environments:

  • Problem: Non-production environments clutter criticality metrics
  • Solution: Use environment tags to separate production from non-production, or exclude non-production from this rule

Applications with varying criticality over time:

  • Problem: Business importance changes with product launches, seasonal traffic, or business strategy
  • Solution: Establish regular tagging review cycles (quarterly or bi-annually) to update classifications

Using criticality tags effectively

Alert and incident management

  • Prioritize notifications: Send critical alerts to immediate response channels (PagerDuty, SMS)
  • Escalation procedures: Define faster escalation paths for high-criticality incidents
  • SLA differentiation: Set different response time targets based on application criticality

Resource allocation

  • Monitoring intensity: Apply more comprehensive monitoring to critical applications
  • Capacity planning: Prioritize performance optimization for high-criticality systems
  • Security focus: Implement enhanced security monitoring for critical business applications

Reporting and analytics

  • Executive dashboards: Focus leadership reports on critical system health
  • Business impact analysis: Correlate incidents with business metrics for critical applications
  • ROI calculations: Justify monitoring investments based on criticality and business value

Advanced tagging strategies

Integration with external systems

  • CMDB synchronization: Sync criticality tags with Configuration Management Database records
  • Service catalogs: Align with IT service management tools like ServiceNow
  • Business applications inventory: Connect with enterprise architecture documentation

Dynamic tagging

  • Time-based criticality: Some applications may be more critical during business hours or specific seasons
  • Event-driven updates: Automatically update criticality during major business events (sales, campaigns)
  • Geographic considerations: Different criticality levels for different regions or markets

Important considerations

  • Business alignment: Ensure criticality levels reflect actual business impact, not technical complexity
  • Regular reviews: Application criticality can change with business strategy and should be reviewed periodically
  • Team consensus: Involve both technical and business stakeholders in criticality decisions
  • Documentation: Maintain clear documentation of criticality criteria and decision rationale

Next steps

  1. Immediate action: Identify and tag applications currently lacking criticality tags, starting with known critical systems
  2. Process establishment: Create a tagging governance process with regular review cycles
  3. Tool integration: Implement automation to maintain tag consistency across deployments
  4. Stakeholder alignment: Ensure business and technical teams agree on criticality classifications
  5. Advance to Level 3: Once criticality tagging is established, focus on service level attainment

For comprehensive guidance on tagging strategies and implementation, see our tagging documentation.

Copyright © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.