Pagination looks simple until the underlying list changes between requests. If you sort only by a value that several records share, or leave the order to whatever the database happens to return, moving to the next page can skip or repeat items. I would settle the ordering contract before choosing the pagination mechanism.
GitHub’s GraphQL pagination guide is a clear example of following an end cursor and checking whether another page exists. A cursor is useful navigation state, but it is not a magical snapshot of a changing dataset. The API still needs to explain what ordering and consistency a caller can rely on.
For an application list, I want a deterministic sort and a unique tie-breaker. If people change the filters or sort direction, the old cursor should not silently carry on with different assumptions. Page size, empty results and the end of the list also deserve ordinary, predictable behaviour. These are small details that become very visible when somebody is working through hundreds of records.
Offset pagination can be perfectly adequate for a bounded list. Cursor pagination can be a better fit elsewhere. Neither choice excuses an unstable order. Start with what “the next page” means to the user, then choose the simplest mechanism that can keep that promise.