Alerts now lead to the incident, and the incident leads to the requests
Alert emails open a page for the incident itself, with the evidence table, the requests behind it, a copyable block rule and a route back from Log Explorer, so a security alert no longer ends in a list of log lines with no context.
An alert used to split its story across two places. The email's button dropped you into Log Explorer with the right rows but none of the explanation, and the card on the Alerts page explained the problem but had no way through to the rows. For hacking-probe alerts there was no evidence link at all.
What changed
- Every alert email now opens the incident, not a list and not raw logs: the headline, what happened, the likely cause and the suggested next step, with a second link, "See the requests behind it", for the log lines.
- A page per incident. The same page is reachable from the Alerts page ("Open the incident page"). It shows the probe table for scanner and injection alerts: each path the address requested, why it matched, how many times, what your server answered, and what our own follow-up fetch found. Below it are the first 50 requests from that address in the alert's period, a timeline of the alert's repeats, and Acknowledge.
- Block this IP. A copyable rule for the platform your logs come from (Cloudflare, AWS WAF, Vercel, Netlify, nginx or Apache), with a check-first link so a shared office address or a monitoring service is not blocked by reflex.
- Log Explorer knows where you came from. Opened from an incident, it names the incident, describes the active filter in words and links back to it.
- Windows match. A one-hour alert now opens a window of just over an hour around the time it fired, rather than falling back to a full day.