Time windows
Strategies for picking the time window — the single highest-leverage choice for diagnosis quality
The time window tells SigSentry where to look. Pick well and you get a clean diagnosis; pick poorly and you get noise (or nothing).
The principle
Tighter is better. A 30-minute window with 200 relevant log lines gives a sharper diagnosis than a 24-hour window with 200,000.
Strategies by situation
| You know... | Pick |
|---|---|
| Roughly when the issue started | A window starting 5 minutes before that, ending 5 minutes after the latest symptom |
| The issue is ongoing | Last 15 or 30 minutes |
| The issue happened sometime today | Use the dashboard's timeline view to find the spike, then pick a window around it |
| Nothing about timing | Last 1 hour. Re-run with a tighter window once you have a better starting point |
Sizing rules of thumb
| Window | When to use |
|---|---|
| 5–15 min | Acute issues with a clear "happening right now" signal |
| 15–30 min | Most production incidents — long enough to capture a pattern, short enough to stay focused |
| 30–60 min | Slow-burn issues, intermittent failures, post-deploy regressions |
| 1–6 hours | Issues that span multiple deploys or environment changes |
| 24h+ | Pattern-matching against historical context. Avoid for a single incident — too noisy |
When to widen the window
If the diagnosis comes back with logsScanned very low (under ~50)
and the result feels generic, the window is probably too narrow.
| Logs scanned | Action |
|---|---|
| < 10 | Window almost certainly too narrow. Widen 2–4×. |
| 10–50 | Borderline. Widen if the result is generic. |
| 50–500 | Good range for most analyses. |
| 500–5,000 | Plenty of evidence. Result should be sharp. |
| > 5,000 | Window probably too wide. Tighten and re-run for a sharper diagnosis. |
When to narrow the window
If the diagnosis identifies multiple unrelated issues or jumps around between services, the window probably caught two separate incidents. Narrow it to the most recent symptom and re-run.
The result schema's timeline field can help — if the timeline shows
gaps of unrelated events, those are clues about the window's size.
Working with intermittent issues
For issues that recur (every 30 minutes, every hour, etc.):
First analysis: capture one occurrence
Pick a window around one specific occurrence. Get a baseline diagnosis.
Second analysis: span multiple occurrences
Widen to capture 2–3 occurrences. Compare results — if root cause matches, the AI is finding signal across iterations. If it diverges, your "intermittent" issue might actually be multiple distinct issues.
Use Watchdog
Once you understand the pattern, set up a Watchdog rule to catch future occurrences automatically.
Time zones
Time windows are stored as ISO-8601 timestamps in UTC. The dashboard
displays them in your browser's local timezone. The API expects UTC
in timeStart and timeEnd; if you pass local-time strings without
a Z suffix, behavior is undefined.
If your team is distributed, picking a window from the dashboard is safer than building one in code.