Understanding resilience scoring

The resilience scoring hierarchy

Concert uses a four-level scoring model to calculate resilience from individual metric evaluations to application-wide scores. Understanding this hierarchy is essential before diving into configuration details. The following table explains the resilience scoring hierarchy.

Table 1. Resilience scoring hierarchy
Level	Name	Description	Aggregation Method
1	Metric	Raw performance data (uptime %, error count, etc.)	Banded linear scoring (0-100), derived from defined metric levels
2	Requirement (NFR)	Collection of metrics measuring a specific resilience aspect	Weighted average of metrics
3	Category	Group of related requirements under a resilience theme	Simple average of requirements
4	Application	Overall resilience health across all categories	Simple average of requirements

Each level aggregates the one below it. Metrics feed requirements; requirements feed categories; categories organize requirements within the resilience posture.

How categories shape your resilience score

Categories are a key level in Concert scoring hierarchy. The categories you select for your resilience profile directly determine which aspects of resilience are measured and how they combine into your application's overall score.

Concert provides eight standard resilience categories:

Availability - Tracks uptime, error rates, and service disruptions.
Integrity - Validates adherence to standards in building and deploying applications.
Maintainability - Evaluates deployment practices, automation, and change management
Recoverability - Quantifies recovery times (MTTR, RTO/RPO) and rollback readiness.
Observability - Measures incident detection, diagnostics, and monitoring coverage.
Scalability - Assesses performance under load and during scaling events
Security - Protects against unauthorized access, breaches, and threats
Usability - Focuses on user-facing metrics like latency and error rate SLOs.

When creating a resilience profile, you actively choose which categories (and therefore which requirements) to include. This selection directly determines:

Which aspects of resilience are measured
How the overall score is calculated (each category contributes equally)
Where your application's strengths and weaknesses lie

Inputs for resilience scoring

Concert calculates a resilience score from the metrics defined in the assigned resilience profile during each aggregation period. The score is created, or updated with each /evaluate API call. The following prerequisites must be met to compute a resilience score:

A resilience profile must be assigned to the application. This defines the requirements and metrics that are relevant for that specific workload.
Metric values must be available. These can be collected automatically (via telemetry) or submitted manually through APIs.
Metric levels and weights must be configured to calculate requirement-level scores that lead to posture-level scores.

Concert customizes scoring logic per application, based on these configurations. Without valid inputs or profile definitions, resilience scoring will either be unassessed or result in incomplete data.

Resilience profile, posture, and aggregation period

To calculate a resilience score, Concert relies on three core elements: the resilience profile, the resulting resilience posture, and the assessment period. Each plays a role in how scoring is configured, executed, and interpreted:

Resilience profile: A resilience profile defines how an application's resilience posture is evaluated. It includes the relevant categories (like Availability or Maintainability) and specifies how each is scored using metrics, levels, and weights. Profiles can be reused across multiple applications with similar requirements. Once assigned to an application, the profile is applied during each aggregation period to calculate scores.
Resilience posture: A resilience posture is the application's current alignment with the expectations defined in the assigned profile. It is expressed as a 0–100 score. An assessment is created only when the /evaluate API is invoked. If the /evaluate API is called again during the same aggregation period, the current assessment is updated with the latest data. Once an aggregation period ends, the next call to the /evaluate API triggers the creation of a new assessment.
Aggregation period: An aggregation period is a period that defines the how Concert aggregates resilience metrics and generates updated resilience scores for your application based on the aggregated metrics. It can be scheduled at regular intervals or triggered manually. A resilience score is created or updated each time the /evaluate API runs within the current period.

Configuration elements that affect scoring

Resilience scores are determined not just by input values, but also by how those values are configured and interpreted. The following settings in the resilience profile impact how metrics contribute to posture scoring:

Metric levels: Each metric includes defined levels that convert raw telemetry values into a 0–100 score. Concert uses banded linear scoring within each level or band, scores are calculated continuously rather than as fixed step values. For example, a metric that falls midway through a band receives a proportionally calculated score such as 70.25 or 83.50, rather than snapping to a fixed value. This provides more granular and accurate scoring.
Metric levels are configured with a scoring direction that determines how values are interpreted:
- Descending levels (higher values are better): For metrics where higher values indicate better performance (for example, availability % or readiness probe success), score increases as the metric value increases.
- Ascending levels (lower values are better): For metrics where lower values indicate better performance (for example, restart count or missing CPU limits), score increases as the metric value decreases.
Metric weights: Each metric has a weight that reflects its importance within the requirement. Metrics with higher weights have a greater influence on the requirement score.

Resilience scoring logic

Concert uses the four-level scoring model described prior to calculate resilience from individual metric evaluations to application-wide scores. Each layer progressively aggregates results to provide a comprehensive view of application resilience. At the requirement level, metrics are combined using weighted averages to reflect their relative importance. Category and application levels use simple averages, treating all inputs equally.

Note: Concert excludes metrics without submitted data from scoring calculations. Omitted metrics are not assigned a score of zero—they are removed from the weighted average calculation entirely. This means applications with incomplete metric coverage may receive higher scores than expected, as only the submitted metrics influence the result.

Level 1: Metric evaluation - Each metric is evaluated against configured levels in the resilience profile. Based on its value and scoring direction (ascending or descending), the system assigns a score between 0 and 100 using banded linear scoring. This approach ensures that scores are calculated continuously within each band rather than as fixed step values, providing more precise assessment of metric performance. Also, derived score is not stored or displayed independently; It is used solely to compute the requirement-level score.
Figure 1. Derived metric score calculation formula

The score is determined by which band the metric value falls into and its position within that band. Scores can have up to two decimal places (for example, 70.25, 83.50) reflecting the continuous nature of the scoring.
Level 2: Requirement (NFR) score - Each requirement aggregates one or more metric scores by using their assigned weights to calculate a weighted average.
Figure 2. Requirement score calculation formula
Level 3: Category score - A category represents a higher-level grouping that brings together multiple related requirements under one resilience theme. For example, the Availability category may include requirements such as Uptime, Probe Success Rate, and Incident Response. Concert calculates the category score by averaging the requirement scores within that group, allowing each requirement to contribute equally to the category’s overall result.
Figure 3. Category score calculation formula
Level 4: Resilience score (overall) - The application-wide resilience score shows the overall resilience health of an application across all categories. Concert calculates this score by averaging all requirement (NFR) scores within the assigned resilience profile. While requirements are grouped into categories such as Availability, Maintainability, and Scalability for organizational clarity, the final application score is derived directly from the requirement scores across all categories.
Figure 4. Application resilience score calculation formula

Complete scoring example

Concert calculates an application’s resilience score from the input metrics that are defined in its resilience profile during each assessment period. The score is generated or updated with every /evaluate API call. This computation progresses through all four levels of the hierarchy.

The following example demonstrates how scoring progresses through all four levels of the hierarchy. We'll start with three metrics from an Availability requirement and follow their aggregation through to the final application score.

Level 1: Metric evaluation

In this example, the Availability requirement includes three metrics: uptime percentage, synthetic probe success rate, and service restart count. Each metric is evaluated against configured levels and assigned a score between 0-100 using banded linear scoring.

Table 2. Scoring inputs for Availability requirement
Metric	Value	Mapped Score (0-100)	Weight	Indicator Type
Uptime %	`92%`	`80`	`3`	Leading
Synthetic probe success rate	`100%`	`100`	`2`	Leading
Service restart count	`5`	`50`	`1`	Lagging

Note: Leading indicators (uptime %, synthetic probes) measure proactive system health. Lagging indicators (restart count) measure reactive responses to failures. In this example, leading indicators are weighted more heavily (weights of 3 and 2) than the lagging indicator (weight of 1). Leading indicators are weighted more heavily because preventive signals are more prioritized over reactive signals in resilience evaluation.

The mapped score shown in the table reflects how the raw metric value is interpreted against its configured level band and scoring direction (ascending or descending) in the resilience profile.

Level 2: Requirement (NFR) score calculation

The three metrics are combined using weighted averages to produce the Availability requirement score:

requirement-level scoring for Availability NFR metrics — Figure 5. Requirement-level scoring for Availability NFR metrics

Availability requirement (NFR) score: (80×3 + 100×2 + 50×1) ÷ 6 = (240 + 200 + 50) ÷ 6 = 490 ÷ 6 = 81.7

Level 3: Category score calculation

The Availability category contains two requirements:

Availability requirement (calculated above):81.7
Regional Availability requirement (example value):88.5

the following example of category scoring calculation — Figure 6. Category scoring calculation

Result: Availability category score = 85.1

Note: The Regional Availability score (88.5) is an example value for demonstration purposes.

Level 4: Application score calculation

Next, Concert calculates the application’s overall resilience score by averaging all requirement (NFR) scores within the assigned resilience profile. Requirements are grouped into categories such as Availability, Maintainability, and Scalability for organizational clarity. However, the final application score is calculated directly from the individual requirement scores across all categories. Each requirement contributes equally to the overall application resilience score.

Table 3. Example of requirement scores contributing to the application score
Requirement	Score
Service uptime requirement	`85.7`
Deployment recovery time requirement	`66.7`
Auto-scaling capacity requirement	`70`

Note: The scores shown are example requirement scores used to illustrate how the overall application resilience score is calculated.

The following illustration shows the overall application resilience score. — Figure 7. Example of application-level resilience scoring based on requirement scores

Application resilience score: (85.7 + 66.7+ 70) ÷ 3= 74.1

Using the resilience score for posture improvements

Once a resilience score is calculated, you can:

View the score in the assessment summary, requirement-level scores, and the overall resilience posture score in the Assessment results panel.
Deep-dive into individual requirements and metric breakdowns to understand what influenced the score.
Identify indicators that reduced posture and generate AI-powered action plans to address them.
Track resilience posture trends across multiple aggregation periods to monitor progress over time.
Add new requirements to the resilience profile as your architecture evolves or metric priorities shift.

A resilience score tells you how aligned your application is with its profile requirements. But a number on its own doesn’t tell you what to do. That’s where risk assessment comes in. Concert automatically maps every score to a risk level (No Risk, Low Risk, Medium Risk, High Risk, or Critical Risk) based on thresholds you configure. That risk level is what drives prioritization and action. To continue, read Understanding resilience risk assessment.