---
title: "HealthKit errorNoData: The Query Ran and Found Nothing"
canonical: "https://aifitnessapi.com/fix/healthkit-error-no-data"
cluster: "Troubleshooting"
primary_query: "healthkit errornodata"
last_reviewed: "2026-09-04"
description: "Apple returns errorNoData when a query has nothing to compute over. How it differs from a silent empty read, and why it usually is not a bug at all."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"HealthKit errorNoData: The Query Ran and Found Nothing\", AIFitnessAPI, https://aifitnessapi.com/fix/healthkit-error-no-data"
---

# HealthKit errorNoData: The Query Ran and Found Nothing

> Apple's documentation states that errorNoData means data is unavailable for the requested query and predicate, and that the system therefore cannot calculate the query's result. It is an explicit answer, not a silent one: HealthKit is telling you the window you asked about had nothing to compute from. That makes it different from an empty sample query, which returns no error and cannot distinguish a denied read from a type nobody has ever written to. In most cases the right handling is an empty state rather than an error, with no retry and no permission prompt.

- Canonical: https://aifitnessapi.com/fix/healthkit-error-no-data
- Last reviewed: 2026-09-04
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "HealthKit errorNoData: The Query Ran and Found Nothing", AIFitnessAPI, https://aifitnessapi.com/fix/healthkit-error-no-data

---

Your statistics query does not come back empty. It comes back with an error — `errorNoData` — and the instinct is to treat that as a failure, log it loudly, and show the user something apologetic. Usually it is none of those things. In most cases it is HealthKit telling you, correctly, that there is nothing in the window you asked about.

## What Apple documents

Apple's documentation states the abstract as: "Data is unavailable for the requested query and predicate." The discussion is where the useful precision lives:

> This error indicates that no data exists that corresponds to a particular query, so the system can't calculate the query's result. [Statistics] queries return this error when HealthKit can't return the data needed to calculate the statistics.

The bracket is ours: Apple links a query class inline there and the link label is lost in plain-text extraction, but the sentence's own words tell you the shape — this is the error you get when a query has to *compute* something and has nothing to compute from. A sum of zero samples is not zero; it is undefined, and Apple returns an error instead of inventing a number.

Two more facts worth keeping straight. Apple's abstract names the *query and predicate* together, so the error is scoped to what you asked for, not to the type in general. And this case is newer than most of the enum: Apple's platform list introduces it at iOS 14.0 and watchOS 7.0, which is why older codebases handle every query failure as one undifferentiated blob.

## The distinction that matters: an error is not silence

This page owns one half of a pair, so let us be exact about the split.

| What you get back | What it tells you |
| --- | --- |
| `errorNoData` from a statistics-style query | The query had nothing to compute over |
| An empty array, no error, from a sample query | Nothing at all — see below |
| A partial series with a recent start date | Possibly a limited-history grant |
| A genuine failure code | A capability, lock, or authorization problem |

The second row is the trap. A sample query that returns empty is genuinely ambiguous — a denied read looks identical to a type nobody has ever written to. Our [HealthKit returning no data](/fix/healthkit-no-data) guide is the isolation procedure for that silence, and [what "no data" actually means](/blog/no-data-means-four-things) separates the distinct conditions that all render as nothing on screen. Neither of those is this page. Here, HealthKit told you something.

The other side of the pair is the state machine: if you never requested authorization at all, you get a different case entirely, covered in [errorAuthorizationNotDetermined](/fix/healthkit-authorization-not-determined).

## Diagnosis order

1. **Confirm the code is really `errorNoData`.** A single `catch` that logs "query failed" makes every case on this page indistinguishable. Log the raw domain and code before anything else; the argument for that discipline generalises in [undocumented HealthKit errors](/fix/healthkit-undocumented-errors).
2. **Widen the predicate.** Re-run the same query over a much larger window. If results appear, the error was accurate and your window was empty — that is a UI question, not a bug. If it still errors with everything open, keep going.
3. **Check the type, not the query.** Many identifiers are simply never populated on most devices: nothing writes them unless a specific sensor or app is present. Check the type against the [HealthKit identifier reference](/healthkit-identifiers) and ask whether any source on that device would plausibly produce it.
4. **Check your day boundaries.** A window computed in UTC against samples recorded in local time can land squarely between the data. This is the most common self-inflicted version of "no data", and the failure mode is laid out in [timezones and day boundaries](/architecture/timezones-and-day-boundaries).
5. **Check whether the store was even readable.** If the device was locked when the background job ran, you would see `errorDatabaseInaccessible` instead — a different failure with a retry policy attached, covered in [HealthKit database inaccessible](/fix/healthkit-database-inaccessible).
6. **Consider that the read may be granted and the history short.** A grant limited to recent history returns a real result set that simply starts later than you expected; that behaviour and the one authorization state you can positively identify are documented in [HealthKit authorization denied](/fix/healthkit-authorization-denied).

## Handling it, as practice

- **Emptiness is a state, not an exception.** Render "no data for this period" as an ordinary result of the screen. An error dialog for a day the user did not wear their watch is a bug in your product, not in theirs.
- **Do not coerce it to zero.** Writing a zero into your own store because a statistics query had nothing to average is how a rest day becomes a data point. That distinction has to survive all the way into your storage layer — the argument is in [missing data and gaps](/architecture/missing-data-and-gaps).
- **Do not retry.** Nothing about the store changes between one attempt and the next. A retry loop against an empty window is pure battery cost.
- **Do not treat it as a permissions signal.** It is tempting to show a "grant access" prompt when a query errors, and it is wrong: this error can arrive with perfect permissions, and re-prompting after a decision does nothing anyway.
- **Separate it in telemetry.** Count `errorNoData` apart from real faults. If it is the top "error" in your dashboard, your dashboard is measuring user behaviour rather than reliability. Related reading: [the HealthKit error that never fires](/blog/healthkit-error-that-never-fires).

## Symptom to action

| What you observe | What it means | What to do |
| --- | --- | --- |
| Error on a narrow window, results on a wide one | Genuinely empty period | Render an empty state |
| Error on every window for one type | Nothing writes that type on that device | Check the identifier and sources |
| Error only in a background run | Possibly a locked store | Check for the database-inaccessible case |
| Empty array with no error | Ambiguous by design | Run the write-then-read isolation |
| Results start unexpectedly recently | Possibly a limited-history grant | Use the authorized start date |

## Where to go next

The complete enum with Apple's own wording sits in the [HealthKit error reference](/healthkit-errors). If your problem is the ambiguous, silent version rather than this explicit one, start from [HealthKit returning no data](/fix/healthkit-no-data). And if you are building the pipeline that has to survive both across thousands of users, the [HealthKit integration guide](/integrate/healthkit) covers the plumbing underneath.

## FAQ

### Is errorNoData a bug in my query?

Usually not. Apple's abstract states that data is unavailable for the requested query and predicate, and the discussion says no data exists that corresponds to the query, so the system cannot calculate a result. Widen the window and re-run: if results appear, the original window was genuinely empty and your app should render an empty state.

[Permalink](https://aifitnessapi.com/fix/healthkit-error-no-data#faq-1)

### How is this different from a HealthKit query that returns an empty array?

An empty array carries no error and no information: a denied read looks exactly like a type with no samples, because Apple hides read authorization by design. errorNoData is an explicit statement that a computation had nothing to work from. One is ambiguous silence you have to isolate; the other is an answer you can act on directly.

[Permalink](https://aifitnessapi.com/fix/healthkit-error-no-data#faq-2)

### Should I ask the user for permission when I get errorNoData?

No. The error can arrive with permissions in perfect order, and re-requesting authorization after the user has already decided does not present the sheet again anyway. Treat it as a data question instead: check the window, the day boundaries, and whether anything on that device ever writes the type you asked for.

[Permalink](https://aifitnessapi.com/fix/healthkit-error-no-data#faq-3)