Alert fatigue is real, and I’m hoping to use Tines to take some of the manual work out of triage. I use Splunk as my SIEM and I’d love to have alerts automatically pulled in, enriched, and routed without me having to touch each one. Has anyone set this up? What does the connection between Tines and a SIEM typically look like?
Ah, alert fatigue. 
This is a great use case for Tines, and Splunk is one of the more common SIEMs people build with.
Tines connects to Splunk (and most other SIEMs) through their APIs or webhook capabilities, and you’ve got workflow ideas to choose from:
- Splunk pushes to Tines: configure a Splunk alert action to send notable events to a Tines webhook the moment they fire. Great for near real-time triage.
- Tines polls Splunk: run a scheduled HTTP Request action that hits Splunk’s search API to pull recent alerts on a cadence. Handy when you’d rather batch things up or don’t want to configure alert actions in Splunk.
Both work well, so it really comes down to your environment and how your Splunk side is set up. Some folks even do a bit of both.
Once alerts land in Tines, the triage loop usually looks like this:
- Parse the fields you care about out of the Splunk event.
- Enrich by running lookups against threat intel sources (VirusTotal, GreyNoise, your internal intel, etc.) and pulling in asset or user context.
- Filter the noise with logic, so known-benign or duplicate alerts get closed or suppressed automatically.
- Route what’s left based on severity or type, into a ticket in Jira or ServiceNow, a Slack or Teams message, or an analyst queue.
A quick tip: dedupe early so the same recurring notable doesn’t spin up a fresh ticket every time it fires.
A few more resources to get you moving:
- The Story Library has plenty of Splunk templates to choose from.
- The Docs cover webhook and HTTP action configuration.
- The Blog has real-world alert triage workflow examples that map closely to this kind of use case.