What Is RPE (Rating of Perceived Exertion)?

RPE stands for rating of perceived exertion — a number a person gives to describe how hard an effort felt to them. That is the whole definition, and the important word in it is felt. RPE is not read off a sensor, derived from a signal, or modelled from other data. Someone is asked a question and answers it.

General information, not training or medical advice. This page explains a term so you can build software around it. It does not tell anyone how hard to train, and nothing here is a prescription or a clinical assessment.

That single property — self-report — is why RPE behaves differently from every other metric in a fitness product, and why it is worth its own page.

Judgement, not measurement#

Heart rate is measured. VO2 max is modelled from measurements. RPE is neither: it is a judgement, produced by a human, about a sensation.

That is not a flaw. Effort is genuinely subjective — the same barbell on the same day feels different after a bad night's sleep, and no wrist sensor knows that. RPE is the only routinely collected training metric that captures the athlete's own read on the situation, which is exactly what makes it useful and exactly what makes it soft.

The consequences are practical, and you should design for all three:

• It is calibrated per person, and calibration drifts. People new to rating effort tend to rate it differently than people who have done it for years, and the same person's sense of "hard" shifts as they get fitter or more familiar with the scale. Comparing raw RPE between two users tells you very little.
• It is contaminated by everything else. Mood, caffeine, temperature, time of day, whether the set was filmed, and whether the person thinks a coach is watching all leak into the number.
• It can be gamed, honestly. Users who learn that reporting high effort makes the app lighten tomorrow's session will — not maliciously — start reporting differently.

None of that makes RPE useless. It makes it a signal to trend and cross-check, not a value to trust to one decimal place.

The two scales you will meet#

Two conventions dominate, and they are conventions — agreed ways of labelling a feeling, not measurement standards.

The 6-to-20 scale is the older one, commonly described as the Borg scale, and the odd range is its signature. Anyone handing you data on a 6-to-20 range is almost certainly using it.

The 0-to-10 scale is the modern default in strength training, and it is commonly described in terms of reps in reserve (RIR) — how many more repetitions the person believes they could have completed. On that convention a rating near the top of the range means very few reps were left, and a lower rating means several were. Being anchored to a countable thing is what makes the 0-to-10 version easier for people to apply consistently than a pure "how hard did that feel" question.

Some products also use session RPE: one rating for the whole workout, multiplied by its duration in minutes to produce a single training-load number. This is also a convention. Treat the product as bookkeeping — an arithmetic summary that makes two sessions comparable in your database — rather than as a physiological quantity.

The rule that matters for software: these scales are not interchangeable, and there is no safe automatic conversion. A 7 means very different things in the two systems. Pick one, store which one you used, and never mix them in the same column.

Nothing in a wearable API gives you this#

Here is the part builders get wrong. Search any wearable or health-data API for a perceived-effort field and you will not find one, because there is nothing to measure. Devices report heart rate, heart-rate variability, GPS traces, steps, sleep, and vendor-computed scores like strain or readiness. Those are sensor readings or models over sensor readings. RPE is user-reported by definition — a wearable cannot observe it.

Vendor "effort" and "intensity" scores are a common source of confusion here. They are computed by the vendor from physiological signals, so they answer a different question: what your body did, not what the person thought about it. They are not RPE under another name, and substituting one for the other silently changes what your feature means.

The practical upshot: RPE is your field, in your schema. It arrives from your own UI, it lives in your own database, and no integration will backfill it. That is unusual and slightly liberating — you control the scale, the prompt, and the collection moment — but it also means the data quality is entirely your responsibility. If you want the sensor-side metrics that do arrive through integrations, our health data types hub covers what each one actually is.

Why apps collect it anyway#

Two features depend on it.

Auto-regulation. The idea is simply that today's plan should respond to today's state. Logged loads and completed reps tell you what happened mechanically; RPE tells you what it cost. A session where every prescribed rep was completed but reported effort was unusually high is a different situation from the same session reported as easy, and only the self-report distinguishes them.

Plan adjustment over time. Progression logic that reads only weight and reps is blind to accumulating fatigue. Feeding reported effort into that logic gives it a second axis. If you are building the generation side of this, AI workout plan generation covers why the progression arithmetic belongs in deterministic, testable code rather than in a model's prose — and RPE is exactly the kind of soft input that must be handled by rules you can inspect, not by vibes.

Both features live most naturally in lifting products, where the per-set structure gives you an obvious place to ask; how to build a strength training app covers the surrounding data model.

Collecting it without wrecking it#

A few things consistently separate usable RPE data from noise:

• Ask close to the effort. A rating given right after a set is about that set. A rating given at bedtime is about the day.
• Make it one tap. A row of buttons beats a slider, and a slider beats a text field. Every extra second of friction costs you completion rate on a metric that is already optional.
• Label the anchors, not just the numbers. Short descriptions attached to the ends and middle of your scale help people apply it consistently. Numbers alone drift.
• Expect nulls, and design for them. Most users will skip most prompts. Any logic that consumes RPE must behave sensibly when it is missing, rather than treating absence as an easy session.
• Never migrate a user between scales silently. If you change your scale, version the field. Re-labelling historical values is data corruption with extra steps.
• Show it as a personal trend. Like HRV, RPE is meaningful against a person's own history and close to meaningless in a cross-user leaderboard.

What RPE is not#

It is not a pain scale, not a safety check, and not a medical signal. A high rating means an effort felt hard; it does not diagnose anything, and a product should never present it as though it did. Keep the copy descriptive — reflect back what the user reported — and leave interpretation of anything health-related to a qualified human.