Network Flow Logs

Network Flow Logs (also referred to as flow data) capture metadata about IP traffic generated by devices across emnify’s mobile core. Use them to observe device connectivity behavior, troubleshoot issues, support security analysis, and meet audit or compliance requirements—without inspecting packet payloads or content.

Each Flow Log record describes observed IP traffic using core network attributes, including source and destination IP addresses, ports, protocol, timestamps, and traffic volume. Records also include hostname attribution and device, session, and network context (for example, organization, endpoint, APN, and serving operator) where available.

With this enrichment, you can identify not only which IP addresses your devices communicate with, but also which domains and services they contact and under which network context.

Flow Log events

Flow Log records are emitted at defined stages of a flow’s lifecycle, indicated by the event_type field:

A flow is identified by flow_id. For flow_update records, bytes_up and bytes_down are incremental values for the reporting window from period_start_ts to period_end_ts. On flow_end, the release_details object explains how and why the flow terminated.

Record fields

Enrichment objects

The following objects are present when the corresponding enrichment is available.

nat_details—NAT translation details:

domain_name—destination name attribution:

pdp_context—mobile network context:

release_details—flow termination details, on the last record of a flow:

Event timing

emnify doesn’t emit Flow Log records on a fixed schedule. For an active flow, a minimum period limits how often updates are emitted, and emnify checks whether a record is due at a regular interval. By default, the minimum period is 60 seconds and the check interval is 10 seconds. Because checks run periodically, records can come several seconds later than the minimum period, and their timestamps don’t fall on exact 60-second boundaries. These differences are expected and don’t indicate lost data. These default values can change.

• flow_start: the first record covers the flow’s first 10 to 20 seconds by default, so you see new flows early. A DNS flow can expire before the first check. Its only record is then a flow_start record that already contains release_details.
• flow_update: 60 seconds is the minimum period between updates, not a fixed schedule. Under continuous traffic, updates are emitted about 60 to 70 seconds apart. If no bytes were transferred since the previous record, emnify emits no update and starts a new window, so a flow’s records can have gaps between them while the flow is idle. If the flow stays idle, it ends when its idle timeout expires.
• flow_end: emnify checks for expired flows about every 3 seconds, so the record is emitted within about 3 seconds after the flow’s idle timeout expires. Its window covers at most about the last 70 seconds of the flow, and often less. Because some idle timeouts are long, the flow_end record can come hours after the previous record.

How a flow ends depends on the protocol:

The idle timeout depends on the flow type. The default values are 30 seconds for ICMP, 3 minutes for UDP, 10 seconds for UDP DNS, 30 seconds for transitory TCP, and 4 hours 8 minutes for established TCP. These values can change.

TCP flow example

A short flow_end window after a longer flow_update is normal for TCP.

UDP flow example

A UDP flow follows the same pattern for flow_start and flow_update. It ends with idle_timeout after the UDP idle timeout elapses without packets. The flow_end record is emitted at the first check after the flow expires, so it appears up to about 3 seconds after the timeout.

Example records

{
  "flow_id": "a1b2c3d4-e5f6-4890-abcd-ef0123456789",
  "org_id": 12345,
  "endpoint_id": 67890,
  "vnet_id": 1,
  "pdp_session_id": "pdp-9f3c1b27",
  "event_type": "flow_start",
  "direction": "egress",
  "protocol": 6,
  "src_ip": "100.64.0.1",
  "src_port": 60570,
  "dst_ip": "104.18.3.24",
  "dst_port": 443,
  "bytes_up": 375,
  "bytes_down": 1154,
  "flow_start_ts": "2026-01-15T10:55:04.731Z",
  "period_start_ts": "2026-01-15T10:55:04.731Z",
  "period_end_ts": "2026-01-15T10:55:16.271Z",
  "nat_details": {
    "translated_src_ip": "100.64.0.1",
    "translated_src_port": 61396,
    "public_ip": "133.7.133.7"
  },
  "domain_name": {
    "hostname": "example.org",
    "source": "TLS_SNI"
  },
  "pdp_context": {
    "mcc": "262",
    "mnc": "02",
    "apn": "em",
    "imsi": "262021234567890",
    "country": { "name": "Germany", "country_code": "49", "iso_code": "de", "id": 74 },
    "operator": { "id": "26202", "name": "Vodafone" }
  },
  "last_loaded_at": "2026-01-15T10:55:30.000Z"
}

{
  "flow_id": "a1b2c3d4-e5f6-4890-abcd-ef0123456789",
  "org_id": 12345,
  "endpoint_id": 67890,
  "vnet_id": 1,
  "pdp_session_id": "pdp-9f3c1b27",
  "event_type": "flow_end",
  "direction": "egress",
  "protocol": 6,
  "src_ip": "10.50.12.34",
  "src_port": 49312,
  "dst_ip": "52.85.77.20",
  "dst_port": 443,
  "bytes_up": 24576,
  "bytes_down": 262144,
  "flow_start_ts": "2026-01-15T10:18:06.000Z",
  "period_start_ts": "2026-01-15T11:02:15.000Z",
  "period_end_ts": "2026-01-15T11:02:41.000Z",
  "domain_name": {
    "hostname": "api.example.com",
    "source": "DNS_REPLY"
  },
  "pdp_context": {
    "mcc": "262",
    "mnc": "02",
    "apn": "em",
    "imsi": "262021234567890",
    "country": { "name": "Germany", "country_code": "49", "iso_code": "de", "id": 74 },
    "operator": { "id": "26202", "name": "Vodafone" }
  },
  "release_details": {
    "release_reason": "tcp_fin",
    "release_side": "device"
  },
  "last_loaded_at": "2026-01-15T11:02:55.000Z"
}