How do you explain a gap in GitHub activity during a review?
Explain a gap in GitHub activity during a review with a clear timeline, relevant work evidence, and honest context—without treating PR counts as a score.
Explain a gap in GitHub activity by naming the period, stating the actual reason, and connecting the work you did to evidence your reviewer can assess. Separate missing public activity from missing work, and acknowledge a genuine delivery shortfall directly rather than trying to make a contribution graph tell a different story.
How do you explain a gap in GitHub activity during a review?
Describe the gap as a bounded period with an explanation, not as a character judgment. For a 2026 review, use the actual review window and distinguish what appears in GitHub from what your role required during that window.
Build your explanation in this order:
- Name the period. Identify the dates your reviewer is asking about.
- State the reason. Explain whether the gap reflects private work, non-coding responsibilities, leave, blocked delivery, or reduced output.
- Show the evidence. Select records that support that explanation.
- Explain the outcome. State what changed, what remains incomplete, or what you agreed to do next.
An existing brag document for software engineers can help you find supporting records without reconstructing the entire period from memory.
Use 1 short paragraph for the initial explanation. Keep supporting material separate so the reviewer can inspect it without losing the main point.
Why this matters
A contribution graph answers a narrower question than a performance review. GitHub documents rules governing which contributions appear on profiles; a visible gap is not, by itself, evidence that you stopped contributing at work.
Your explanation still needs evidence. Replacing a thin graph with an unsupported claim about invisible work does not help a reviewer understand your contribution.
For your 2026 review, establish what is being evaluated: delivery against agreed responsibilities, collaboration, technical decisions, or something else. Then choose records that address those expectations rather than assembling a larger pile of activity.
The useful distinction is between an incomplete activity record and an unmet commitment. The first calls for context; the second calls for accountability as well as context.
Match the explanation to the actual gap
Different situations need different evidence. Choose the row that describes what happened, not the explanation that sounds most favorable.
| Situation | Best for | Evidence to bring | Limitation |
|---|---|---|---|
| Private repository work | Explaining missing public activity | Authorized internal PRs or approved summaries | Public readers cannot independently inspect private records |
| Planning, reviews, or support | Explaining work outside authored merges | Design decisions, review threads, incident records, or documentation | Participation alone does not establish an outcome |
| Leave or an agreed absence | Establishing the expected working period | The agreed dates and relevant work expectations | Personal details are not needed to assess delivery |
| Blocked or unfinished work | Explaining why work did not reach merge | Issue history, dependencies, and escalation records | Effort does not turn unfinished work into delivery |
| Reduced delivery | Addressing a genuine shortfall | Original commitment, actual result, and corrective action | Context does not erase a missed commitment |
Do not combine every possible explanation into your answer. If a dependency blocked a specific change, explain that dependency and its effect; do not also imply that all missing activity came from private work unless that is true.
Build an explanation your reviewer can verify
Start with the records, then write the narrative. This keeps your account tied to what happened rather than what you wish the activity graph showed.
Establish scope
Confirm the dates, repositories, and type of activity under discussion. A public profile, a repository search, and a list of merged PRs are different views; do not describe them as interchangeable.
For a January–March 2026 review, check whether the apparent gap concerns that entire period or only part of it. Also check whether your reviewer is asking about authored code, completed work, or broader contribution.
Check records
Search the repositories and work systems you are authorized to use. Look for merged work, unfinished work, reviews, decisions, support activity, and agreed absences relevant to the question.
Use 2 supporting records as a starting point, not a quota. A clear decision record and the resulting change can explain more than a long list of unrelated comments.
Connect outcomes
Explain what the records demonstrate. A design document can support a claim that you evaluated an approach; it does not automatically support a claim that the approach shipped successfully.
Separate your contribution from the team's result. State whether you authored the change, reviewed a risk, investigated a failure, or helped someone else complete the work.
State next steps
If expectations were met but the record was incomplete, agree on a better way to capture the work. If expectations were missed, name the delivery change you will make and how you will discuss progress.
Avoid promising a higher contribution count as the remedy. The next step should address the actual issue: scope, dependencies, communication, or completing the agreed work.
What changes the explanation you should give?
The reason for a gap determines what evidence belongs in your review. Check these factors before drafting your 2026 self-review:
- Record visibility. Public activity does not expose the contents of private organization repositories. Keep internal evidence within approved channels.
- Role expectations. If your assigned work centered on reviews, design, or support, explain those responsibilities instead of presenting authored merges as the entire job.
- Completion status. Distinguish merged work from proposals, investigations, and changes still in progress. Each supports a different claim.
- Working period. Account for agreed leave or a change in assignment when describing what you were expected to deliver.
- Dependencies. Identify the decision, access, review, or upstream work that blocked progress, along with any escalation you made.
- Actual delivery. If you delivered less than agreed, state that plainly. Add context without rewriting the commitment after the fact.
These factors explain differences in the record; they are not automatic defenses. Your reviewer still needs to understand your responsibility, your actions, and the result.
What should I say if the work was private?
Explain that the public record excludes the work, then provide evidence through an authorized internal channel. Name the kind of contribution and its outcome without exposing repository contents to an audience that lacks access.
For an internal 2026 performance review, relevant evidence can include an internal PR, an approved project summary, or a decision record. Choose the record your reviewer is permitted to see, not the most technically detailed artifact.
For a job search, use an employer-approved description of the problem and your contribution. Do not copy proprietary code, internal issue text, customer information, or repository screenshots into a personal portfolio to make a gap look smaller.
If disclosure is restricted, explain the scope of your role at an appropriate level. A truthful, limited description is better than implying that confidential work can be independently verified on your public profile.
What should I say if I genuinely delivered less?
State the shortfall, explain its cause, and describe the correction. Keep the missed outcome visible instead of burying it under a list of meetings, comments, or hours spent.
A useful outline is: the commitment you made, what you completed, what prevented completion, and what you changed. Include your own decisions where they contributed to the result.
If you raised a blocker late, say so. If the scope was unclear, explain how you will confirm acceptance criteria before starting the next piece of work.
For a 2026 review, tie the next step to the next agreed checkpoint rather than inventing a dramatic recovery target. Your goal is a credible account and a workable plan, not a promise to generate more GitHub events.
When a merged-PR history helps
Pulltally is best for individual developers who need to revisit merged GitHub pull requests without repeating manual searches. You can browse and summarize merged PRs by month, organization, or personal repository when reconstructing a review period.
That is useful when the question is what you merged during the surrounding months. It is not enough when the explanation depends on unmerged work, a design decision, leave, or an incident response; bring the appropriate records for those claims.
Pulltally uses read-only access to pull request metadata. Signing in alone does not connect private organization repositories, so do not assume that authentication makes private organizational work available.
Treat the resulting history as a starting point for your account. Personal delivery history, not a productivity score. A merged PR establishes that a change was merged; your review still needs an explanation of its purpose and your contribution.
Keep your review paragraph short
Write the explanation after you have selected the evidence. Lead with the fact your reviewer needs, then add context and the result.
Use 4 sentences as a drafting limit:
- State the period and what the visible record omits or accurately reflects.
- Explain your responsibility during that period.
- Identify the supporting record and what it demonstrates.
- State the outcome or the next agreed action.
Do not use a template to manufacture a favorable explanation. Remove any sentence you cannot support, and expand only when the reviewer asks for detail.
Before the conversation, check that your written self-review and your spoken explanation describe the same events. Small differences in dates, ownership, or completion status distract from an otherwise straightforward account.
FAQ
Does a gap in my GitHub graph mean I performed poorly?
A gap in your GitHub graph does not establish poor performance. Compare the visible record with your agreed responsibilities and the evidence of what you delivered.
How do I explain private repository work in a performance review?
Explain the work using records your reviewer is authorized to access. For an external audience, use approved descriptions rather than exposing private code or internal repository details.
What if I spent the period reviewing code instead of writing it?
Describe the review responsibility and the decisions or changes your reviews supported. Review activity is relevant evidence, but the number of comments alone does not establish its value.
Do I need to explain personal details about medical or family leave?
Keep the performance discussion focused on the agreed absence and the work expectations for that period. Use the appropriate workplace process for any required personal documentation.
Can Pulltally explain why I had no merged PRs?
Pulltally helps you browse and summarize merged GitHub pull requests; the reason for a gap still needs your context. Access is read-only, and signing in alone does not connect private organization repositories.
Should I make small commits to fill the activity gap?
Do not create activity just to change the appearance of your graph. Explain the actual work and address any missed commitment with a delivery plan instead.
What evidence should I bring if my work never merged?
Bring records showing the investigation, decision, blocker, or unfinished change relevant to your responsibility. Label the work as unmerged and explain its actual result rather than presenting it as shipped delivery.
One last thing
Preserve the difference between the date work happened and the date it merged. If a change crossed your review boundary, describe that sequence rather than moving the whole contribution into whichever period makes the activity record look better.
For your 2026 review, add a brief note wherever that distinction changes the explanation. A clear timeline is more useful than a fuller-looking graph.
