The first alert is rarely the first activity
An alert timestamps when you noticed, not when it started. An investigation that begins at the alert inherits the attacker's head start.
An alert has a timestamp, and it is tempting to treat that as the beginning.
It is not. It is the moment one particular rule matched one particular step of something already in progress. Whatever the attacker did to reach that step happened earlier, and none of it is inside the window you just opened.
Scope forward from the alert and you investigate the tail. You will find what happened next, close the case, and never learn how they arrived, which is the answer you actually needed for two reasons: it tells you whether the entry route is still open, and whether anything else came through it.
So work backwards first. Take the entity in the alert, a host or an account, and widen the window until the activity looks ordinary again. Then look at what changed just before it stopped looking ordinary.
The other habit worth building is not trusting the alert’s own account of what is interesting. The rule matched one behaviour. The same entity may have done five other things that no rule watches, and those are visible in the raw data around it if somebody looks.
Next time you triage, note the alert time, then set your window to start twenty-four hours earlier before you begin. Notice how often something is already there.
CHECK YOURSELF
An alert fires at 14:00 on a host. Where should the investigation's time window begin?
SHOW THE ANSWER
Earlier than 14:00, because the alert marks detection rather than the start
Why. A detection fires on one step of a sequence, and steps came before it. Starting at the alert scopes the investigation to the tail and reliably misses initial access, which is the part that tells you how they got in and whether they are still there. Retention is a boundary you will eventually hit rather than a place to start from, and shift times have nothing to do with when anything happened.