Start with the log, not with guesses
When something on your GitHub account looks different, the useful first move is to pull a record you control rather than reconstruct events from memory. GitHub’s personal security log is that record.
GitHub’s personal security log contains actions from the last 90 days. Source
Because the log is bounded to a recent window, export early. Events that fall outside the window will not appear later, and you cannot recover them by waiting.
Where the log lives and what you can filter
The log is available in account Settings under Archives, Security log and supports filters such as actor, repository and action. Source
The filters matter more than the raw volume. Narrowing by actor, repository or action lets you isolate the period and surface you care about, instead of scrolling through unrelated routine activity.
Export a private copy before you analyse
The Export menu downloads JSON or CSV; supported filters can narrow the export. Source
Treat the exported file as sensitive. It contains a record of account activity, including actors and actions, and it may reveal personal or organizational context. Keep it somewhere private, share it only with people directly helping you investigate, and avoid pasting it into public threads or issue trackers. If you later need to hand a copy to a platform support team, share the narrowest filtered export that answers their question.
Build an incident timeline worksheet
A log export is a list of events, not a narrative. Convert it into a worksheet so that observations, interpretations and open questions stay separate. A simple structure works:
| Column | What goes in it | Why it matters |
|---|---|---|
| Event | A short label for what happened | Makes the row scannable later |
| Time | The timestamp as recorded, with time zone noted | Prevents ordering mistakes |
| Actor | The account or identifier recorded as acting | Identifies the recorded source, not a person |
| Action | What the log says was done | Keeps the row factual |
| Confidence | How sure you are that this row is relevant and correctly read | Separates strong rows from speculative ones |
| Open question | What you still need to check | Stops assumptions hardening into facts |
Fill the worksheet from the export, one row per event you decide is relevant. Use the confidence column honestly: a row you have read directly from the export is stronger than a row you inferred from a change you noticed. Where you noticed a change but cannot find a matching event, record that as an open question rather than a conclusion.
Separate observed actions from proof of who did them
This is the part most timelines get wrong. An entry in the log tells you what the record says happened and which actor identifier is attached. It does not, on its own, establish which human being was at the keyboard. Shared devices, reused sessions, compromised credentials and legitimate automation can all produce entries that look like a person acting.
Keep two columns of thinking in your head as you review:
- Observed: the event, time, actor and action as recorded.
- Not established: who physically performed it, why, and whether the actor identifier corresponds to the person you assume.
Write conclusions in the second category only when you have independent evidence. Until then, they belong in the open-questions column.
Do not read a missing event as proof of nothing
A blank space in the export is not evidence of inactivity. The log covers a defined recent window, and an export reflects the filters you applied. If you filtered by a repository, events in other repositories will not appear. If the change you are worried about happened outside the window, it will not be there. Record absences as gaps to investigate, not as reassurance.
If you have lost access
If you cannot sign in to reach the log at all, stop trying to reconstruct events from the outside and use GitHub’s official account recovery process. Recovery is the path that restores your ability to review the account. Do not ask third parties to access the account on your behalf, and do not treat a password reset alone as a completed investigation; once access returns, export the log and build the timeline for the period around the change.
A short checklist
- Export the security log before the 90-day window rolls forward.
- Store the export privately and note the date and time zone of the export.
- Apply filters to isolate the period and surface you care about, then export the narrowed view if it helps.
- Build the worksheet with event, time, actor, action and confidence columns.
- Mark each row as observed or inferred, and keep open questions separate.
- Record missing events as gaps, not as proof of nothing.
- If access is lost, use official recovery first, then return to step 1.
A useful next step
Once you have a timeline, the next question is often which other accounts are connected to the same name or identifiers. That is a different task from reading a security log, and it has its own method: see how to find all accounts linked to a name. Keep the two investigations separate so that findings from one do not get mistaken for evidence in the other.