Skip to main content
Solved

Sentinel Destination Failing With 401 And 400 Errors Despite Working On Other Worker Groups

  • January 20, 2026
  • 2 replies
  • 5 views
D
This message originated from Cribl Community Slack.
Click here to view the original link.

Hey all, i'm troubleshooting a sentinel destination, trying to get SecurityEvent logs into the SecurityEvent table in sentinel, I have the same destination on 4 other worker groups, and they appear to be healthy. Allowed the traffic outbound to the Azure DCR url and login on my firewall so I don't believe there's a network error: Getting this error instead: I have tried back pressure set to PQ, and it appeared to be writing into the disk and then set back to block to test around. I've already tried restarting the worker nodes and still getting the same error. I clone the destination on a different worker group again to test and it work. The volume isn't anything crazy, 20-30gb in total going through, or should be. I'm getting 401 and 400 errors but not sure if its authentication related since the exact same destination with same auth configs is working on the other worker groups. Would appreciate some input on this.Thanks!

Links for this message:
image.png

Best answer by dbizon539

401 would be authentication errors but a case would need to be open to see what is happening before these errors occur for you. 400 is a bad request which typically means the payload is not in the expected way Sentinel is wanting (in general terms at least). It does show Sent Count but there are events in buffer and bytes in buffer. Based on your description though - something seems up with that worker group in the network that is causing this. You have no issues with other worker groups with the same destination. Maybe firewall? From the worker experiencing issues - have you tried cURLing the destination to make sure you can get out from the worker?

2 replies

D
  • dbizon539
  • Employee
  • Answer
  • January 20, 2026
401 would be authentication errors but a case would need to be open to see what is happening before these errors occur for you. 400 is a bad request which typically means the payload is not in the expected way Sentinel is wanting (in general terms at least). It does show Sent Count but there are events in buffer and bytes in buffer. Based on your description though - something seems up with that worker group in the network that is causing this. You have no issues with other worker groups with the same destination. Maybe firewall? From the worker experiencing issues - have you tried cURLing the destination to make sure you can get out from the worker?
D
  • david.phan648
  • Author
  • New Participant
  • January 20, 2026
@user I did open a support ticket waiting to hear back from Cribl. I don't think there's a firewall blocking it because I created another sentinel destination pointing towards the CommonSecurityLog table, using the same credentials I used for my other sentinel destination on this worker group and have been testing sending logs and I've received it on the sentinel side. It might be something with the DCR, but at the same time, I have like 4 other worker group sending logs to that DCR without any issues. The fleet that is sending logs to this worker group has the Sentinel Pack on it and doing a live capture on that source shows the logs are formatted correctly for the sentinel destination. When I route those logs to a different worker group and then point to Sentinel, they are sending just fine as expected.
Terms & ConditionsAccessibility statement