# Elastic Defend api/endpoint/metadata: Pagination stuck when more than pageSize endpoints share the same last\_checkin timestamp

**URL:** <https://discuss.elastic.co/t/elastic-defend-api-endpoint-metadata-pagination-stuck-when-more-than-pagesize-endpoints-share-the-same-last-checkin-timestamp/386844>\
**Category:** Kibana\
**Created:** [June 12, 2026, 6:44pm UTC](https://discuss.elastic.co/t/elastic-defend-api-endpoint-metadata-pagination-stuck-when-more-than-pagesize-endpoints-share-the-same-last-checkin-timestamp/386844 "2026-06-12T18:44:47Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![d7d929022f550dc3d90e](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@d7d929022f550dc3d90e](https://discuss.elastic.co/u/d7d929022f550dc3d90e)\
**Post date:** [June 12, 2026, 6:44pm UTC](https://discuss.elastic.co/t/elastic-defend-api-endpoint-metadata-pagination-stuck-when-more-than-pagesize-endpoints-share-the-same-last-checkin-timestamp/386844/1 "2026-06-12T18:44:48Z")

</div>

We are paginating through all endpoints using the Kibana `api/endpoint/metadata` API. The API does not support `PIT` or `search_after`, so we are using cursor-based pagination with  
`sortField=last_checkin`, `sortDirection=asc`, and advancing via a kuery filter:

kuery: `last_checkin >= ""`

We always keep `page=0` and advance the cursor to the `last_checkin` of the last endpoint in each batch, staying within Elasticsearch's 10,000-result window.

The Problem:

When more than pageSize (`100`) endpoints share the exact same `last_checkin` timestamp, the cursor never advances. Every subsequent request returns the same batch of `100` endpoints  
with the same timestamp, causing the pagination loop to run indefinitely without making progress.

Example scenario:

- Page 1 returns 100 endpoints, all with last\_checkin = "2024-01-15T10:00:00Z"
- Cursor is set to "2024-01-15T10:00:00Z" and next request uses kuery: last\_checkin \>= "2024-01-15T10:00:00Z"
- Page 2 returns the same 100 endpoints again — loop is stuck

What we've tried:

- Tracking seen agent IDs at the current cursor timestamp to skip duplicates across page boundaries — this works for overlap between two consecutive timestamps, but breaks down  
when an entire batch (or more) shares one timestamp.
- Using \> instead of \>= in the kuery — this causes us to skip all endpoints at the current timestamp entirely and miss data.

Questions:

1. Is there a way to use page + pageSize with sortField=last\_checkin to paginate through a group of endpoints that all share the same timestamp (i.e., is there a stable secondary  
sort key available in this API)?

2. Does the `api/endpoint/metadata` API support any tiebreaker sort field (e.g., agent.id) that could be combined with last\_checkin to make each page's cursor unique?

3. Is there a recommended approach for paginating after 10,000 endpoints using the Kibana API? We are aware of PIT + search\_after on the underlying metrics-endpoint.metadata\_united\_default index but wanted to confirm if there's a supported API-level solution first.

4. Is there any other API endpoint that we can use to fetch the same information?

---

<div class="post-metadata">

**Author:** ![Rafa\_Silva](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rafa_silva/32/147814_2.png) [@Rafa\_Silva](https://discuss.elastic.co/u/Rafa_Silva)\
**Post date:** [June 13, 2026, 1:36am UTC](https://discuss.elastic.co/t/elastic-defend-api-endpoint-metadata-pagination-stuck-when-more-than-pagesize-endpoints-share-the-same-last-checkin-timestamp/386844/2 "2026-06-13T01:36:58Z")

</div>

Hey Rushit! Great catch on that pagination issue. Here’s the straightforward answer:

The Problem: When multiple endpoints share the same last\_checkin timestamp, the cursor can’t distinguish between them, so it loops.

The Solution: The api/endpoint/metadata endpoint doesn’t support tiebreakers, but use the Elasticsearch Search API directly with PIT + search\_after instead:

```json
{
  "pit": { "id": "your_pit_id", "keep_alive": "5m" },
  "size": 100,
  "sort": [
    { "last_checkin": { "order": "asc" } },
    { "_id": { "order": "asc" } }
  ],
  "search_after": ["2024-01-15T10:00:00Z", "agent_id_here"]
}

```

The \_id field is always unique and acts as your stable tiebreaker — this handles duplicate timestamps perfectly and works for 10K+ results.

Official docs: [Paginate search results | Elasticsearch Reference](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/paginate-search-results)

That’s the recommended approach for your use case. Let me know if you need the PIT setup details!