GitHub Issues & PRs Scraper - Bulk Repository Data

Export all issues and pull requests from a GitHub repository as one clean table. Useful whenever the GitHub UI is too slow to answer a question like "how long do PRs stay open here" or "which labels dominate this backlog".

What you get per item

Field	Example
number	1842
title	Fix retry logic on streaming responses
type	issue or pull_request
state	open, closed
author	the account that opened it
labels	["bug", "priority/high"]
commentsCount	12
createdAt, closedAt	timestamps, so time-to-close is a subtraction
url	link to the item

Input

• repository - owner and name, e.g. openai/openai-python
• includeIssues - include issues
• includePulls - include pull requests
• state - open, closed or all
• maxItems - how many items to save

Example input

{
  "repository": "openai/openai-python",
  "includeIssues": true,
  "includePulls": true,
  "state": "all",
  "maxItems": 500
}

Use cases

• Open source due diligence - before adopting a dependency, measure how fast issues actually get closed
• Project health analytics - track open/closed ratio, label distribution and comment volume over time
• Competitive intelligence - watch what users complain about in a competitor's repository
• Maintainer reporting - build a backlog report without clicking through pages of the GitHub UI
• Developer research - find the most active contributors and reviewers in a project
• Support and product insight - mine issue titles for recurring feature requests

Why export rather than browse

GitHub's interface answers one question at a time. A table answers aggregate questions: median time to close, which labels correlate with long threads, whether PR throughput is rising or falling. Because createdAt and closedAt are both present, duration analysis needs no extra requests.

Notes

• type distinguishes issues from pull requests, since GitHub stores both in the same numbering sequence.
• closedAt is empty for open items.
• Labels are repository-defined, so they differ in meaning between projects; compare within a repository rather than across.
• Very large repositories should be run with state and maxItems narrowed, or in slices, rather than in one pass.