Why two apps show different total descent for the same hike

The short answer

Total descent is built the same way elevation gain is — walk from one recorded altitude reading to the next, and whenever the second is lower than the first, add the difference to a running total. Because altitude is the noisiest figure a phone records, that running total inherits the same sensor wobble elevation gain does, and two apps rarely filter or process it identically. On top of that ordinary noise, descent has its own extra source of disagreement: some services define it as the sum of every downward step, the same way gain sums every upward one, while others quietly report something closer to a net change in height instead. Those are not the same number, and mixing them up explains a lot of the gap that noise alone does not.

The same noise that affects elevation gain affects this too

A phone's altitude reading wanders more than its latitude and longitude does, because the satellite geometry that pins down height is weaker than the geometry that pins down a horizontal position. Some devices and services lean on that raw GPS altitude; others read a barometric pressure sensor instead, which smooths out short-term jitter but drifts with ordinary weather over the course of a few hours. Either way, a total built by summing thousands of small altitude changes carries all of that wander forward, and descent sums changes exactly the way gain does, just in the other direction. None of this is specific to descent — it is the same mechanism behind two apps disagreeing on elevation gain for the identical walk.

What is different about descent specifically

Elevation gain is the figure most hiking and cycling platforms treat as a headline stat, so most of them define it the same way: a running sum of upward steps. Descent gets treated far less consistently. A service built around climbing, like most hiking apps, tends to sum downward steps the same careful way it sums upward ones. A service built more around logging a workout than describing a route sometimes reports "descent" as simply the difference between the highest and lowest point reached — which is a real number, but a different one, and can come out noticeably smaller than a true summed total on any hike with more than one climb and descent in it.

A hike with two smaller descents adding up to 300 metres of downhill walking, separated by a short climb back up in between, sums to 300 metres of descent under the first definition. Under the second, it is simply the gap between the highest point and the lowest point on the route, which can land well under that if the lowest point was reached partway through rather than right at the end. Neither app is wrong about what it is reporting — they are answering two different questions that both happen to be labelled "descent."

Descent is also the figure some services just do not surface

A fair number of platforms show elevation gain prominently on a hike's summary page and leave descent buried a tab deeper, in a CSV export, or out of the interface altogether. That is not the same problem as a mismatched number — nothing is being calculated incorrectly — but it produces the same symptom people are usually trying to explain: open two apps side by side, one shows a clear descent total and the other seems to show nothing, or a number that turns out to be something else, like net elevation change, standing in for it.

Elevation correction affects descent the same way it affects gain

Some platforms discard the altitude a device actually recorded and look up an elevation instead from a terrain database, using only the latitude and longitude of each point. Gain and loss both get recalculated from those looked-up values rather than from what your phone measured on the day. A terrain-corrected descent total tends to be smoother and more repeatable than a raw-sensor one, since it is describing the shape of the ground rather than a live reading with weather and signal quality baked into it — which is exactly why it can land some distance from a total another app built out of raw altitude.

What to actually do about it

• Check what the two figures are actually measuring before assuming one is wrong — a summed total of every downhill step and the gap between a route's highest and lowest point are both legitimate numbers, and they answer different questions.
• Look for whether a service uses raw device altitude or a terrain database for its elevation figures, since that single choice explains a large share of any gap on its own.
• Treat a route's own history in one app, recorded and processed the same way each time, as the more trustworthy comparison than any single figure matched against a different service.

Where TrailCam fits in

TrailCam reports elevation gain alongside distance, moving time and pace for every recorded route, and shows the elevation profile underneath a replayed hike, so the downhill sections of a walk are visible directly on the curve rather than reduced to one separate descent total. A route exports as GPX 1.1 or CSV, both part of the optional TrailCam Pro upgrade, carrying the same altitude readings any other service would use to compute its own descent figure from the file. TrailCam is free to download.