# Suricata lots of flow never timeout
**URL:** https://forum.suricata.io/t/suricata-lots-of-flow-never-timeout/6122
**Category:** Help
**Created:** [November 29, 2025, 6:48am UTC](https://forum.suricata.io/t/suricata-lots-of-flow-never-timeout/6122 "2025-11-29T06:48:09Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Xman](https://forum.suricata.io/u/Xman)
#### Post date: [November 29, 2025, 6:48am UTC](https://forum.suricata.io/t/suricata-lots-of-flow-never-timeout/6122/1 "2025-11-29T06:48:09Z")
Version info(from github install):
suricata --build-info
This is Suricata version 8.0.2 RELEASE
Features: PCAP\_SET\_BUFF AF\_PACKET NETMAP HAVE\_PACKET\_FANOUT LIBCAP\_NG HAVE\_HTP\_URI\_NORMALIZE\_HOOK PCRE\_JIT HAVE\_NSS HTTP2\_DECOMPRESSION HAVE\_LUA HAVE\_JA3 HAVE\_JA4 HAVE\_LIBJANSSON TLS TLS\_C11 MAGIC RUST POPCNT64
SIMD support: SSE\_4\_2 SSE\_4\_1 SSE\_3 SSE\_2
Atomic intrinsics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 11.4.0, C version 201112
compiled with \_FORTIFY\_SOURCE=2
L1 cache line size (CLS)=64
thread local storage method: \_Thread\_local
compiled with LibHTP v8.0.2
I use tcpreplay send 1.1GB pcap 100 times to suricata,stats show no packet drop
capture.kernel\_drops": “0”,
“capture.kernel\_packets”: “431647396”,
“decoder.arp”: “0”
when stop tcpreplay for longtime(more than 30 min),stats still show lots of udp flow notimeout
“flow.mgr.flows\_checked”: “11396362”,
“flow.mgr.flows\_evicted”: “420218”,
“flow.mgr.flows\_evicted\_needs\_work”: “1840”,
“flow.mgr.flows\_notimeout”: “10978514”,
“flow.mgr.flows\_timeout”: “417848”,
“flow.mgr.full\_hash\_pass”: “1295”,
“flow.mgr.rows\_maxlen”: “7”,
“flow.mgr.rows\_per\_sec”: “104856”,
“flow.recycler.queue\_avg”: “23”,
“flow.recycler.queue\_max”: “19178”,
“flow.recycler.recycled”: “418378”,
“flow.spare”: “3095452”
Here is may config,I have try change udp flow timeout many time, still not work
flow:
memcap: 4gb
hash-size: 1048576
prealloc: 700000
managers: 4
recyclers: 4
flow-timeouts:
default:
new: 30
established: 300
emergency-new: 10
emergency-established: 100
tcp:
new: 60
established: 300
closed: 120
emergency-new: 10
emergency-established: 300
emergency-closed: 20
udp:
new: 30
established: 300
emergency-new: 10
emergency-established: 300
icmp:
new: 30
established: 300
emergency-new: 10
emergency-established: 100
stream:
memcap: 2gb
reassembly:
memcap: 20gb
depth: 128kb
So whers is these flows “flow.mgr.flows\_notimeout”: “10978514”, these flows was already droped or still in flow.mgr, How can I flush them out to eve output?
Thank you for your help.
---
### Author:  [@vjulien](https://forum.suricata.io/u/vjulien)
#### Post date: [November 29, 2025, 9:34am UTC](https://forum.suricata.io/t/suricata-lots-of-flow-never-timeout/6122/2 "2025-11-29T09:34:55Z")
flows\_notimeout should be compared with flows\_checked. Flows are checked for timeout by the flowmanager on an interval, and the notimeout counter simply reflects how often flows were checked but not yet timed out. It’s not a reflection of flows never timing out for some reason.
---
### Author:  [@Xman](https://forum.suricata.io/u/Xman)
#### Post date: [November 29, 2025, 10:00am UTC](https://forum.suricata.io/t/suricata-lots-of-flow-never-timeout/6122/3 "2025-11-29T10:00:04Z")
Thank you for your explaination,even flows\_notimeout cause flows output, But I still has the problem. stats show “capture.kernel\_packets”: “431647417”,and tcpreplay show Actual: 440181000 packets (65221941400 bytes) sent in 1395.80 seconds
Rated: 46726981.5 Bps, 373.81 Mbps, 315359.04 pps
Flows: 429633 flows, 307.80 fps, 43974600000 flow packets, 5730000 non-flow
Statistics for network device: cap1
Successful packets: 440181000
Failed packets: 100
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
I can see suricata did not drop packet. I get 158.1K flows output by eve log( get 154007165 pkt sum by all flows pkts\_toclient+ pkts\_toserver),That means all flows get only 34% packets, May I know **What causes the total number of packets across all flows to be much smaller than `capture.kernel_packets`?**
I have arkime capture on same NIC at same time, arkime get 2094786 flows logs,and get 98.37% pkts (433019587/440181000),Seems work good.