Site & team management /Monitor sites /Logs /

Log Drains

This feature is available on Enterprise plans.

The Log Drains feature allows you to connect site traffic logs, function logs, and edge function logs from Netlify’s CDN to third-party monitoring services for analysis, alerting, and data persistence. Additionally, this feature allows you to connect deploy logs from our builds service.

Once you’ve configured a log drain for a site, Netlify batches the site’s log records from our CDN and build system and posts them to an endpoint in JSON/NDJSON format in near real-time. A configured external monitoring provider receives these records from the intake endpoint and makes them available for processing. You can drain the following data:

site traffic log output: tracks visitor requests for assets and pages.
function log output: tracks information such as function invocations.
edge function log output: tracks edge functions that output console log statements.
deploy log output: tracks deploy information gathered while building and deploying a site.
Web Application Firewall (WAF) log output: tracks WAF rules matching requests.

If your site will handle HIPAA-regulated data, visit our Trust Center to download and read our reference architecture for HIPAA-compliant composable sites on Netlify before configuring a log drain.

# Configure a log drain

To set up a log drain, you must be a Netlify Team Owner and have an account and API key provisioned with an external monitoring provider. Netlify supports integration with:

Datadog
New Relic
Axiom
Azure Monitor
Sumo Logic
Splunk Observability Cloud
Logflare
Amazon Simple Storage Service (Amazon S3)
General HTTP endpoints

# Datadog

For your selected site, go to
Logs Log Drains
and select Enable a log drain.
Select Datadog as the Log drain service.
Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
Optional: add Traffic log filtering. If you’re draining traffic logs and don’t want client_ip and user_agent in the data, select Exclude personally identifiable information (PII).
Under Service settings, select the Region where your Datadog site is located.
Enter the unique API key for your logging service provider account. Verify that you are entering your API key instead of the Datadog application key.

Optional: add key/value pairs under Tags to tag your logs with certain attributes. These become query parameters in requests to the logs intake endpoint.

Available keys for Datadog:

Key	Tag Description	Example value
`ddtag`	tags associated with logs, grouped into a single list with the value `ddtags`	`env:prod`
`service`	name of the application or service generating the log events	`mysubdomain`

Select Connect.

Key	Value	Tag description
`environment`	`production`	environment type
`service`	`mysubdomain`	name of the application or service generating the log events

# Amazon S3

To configure a log drain that sends logs to your Amazon S3 account as Gzip-compressed files, you need to:

Create an Amazon S3 bucket and set up a bucket policy
Configure the log drain in the Netlify UI

# Create an Amazon S3 bucket and set up a bucket policy

In the AWS Management Console, create an S3 bucket.
- Object Ownership for the bucket should be set to either Bucket owner enforced or Bucket owner preferred.
- Make note of the bucket name to use in your Netlify configuration.
Go to your bucket’s Permissions and under Bucket policy select Edit.

Copy and paste the following bucket policy, replacing YOUR_BUCKET_NAME with the name of your Amazon S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NetlifyLogDrains",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::128866310339:role/log-shipper"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}

Select Save Changes.

Bucket lifecycle

For cost control reasons, we recommend deleting logs after a period of 90 days. You can configure your Amazon S3 bucket to delete logs automatically by setting lifecycle rules.

# Configure the log drain in the Netlify UI

For your selected site, go to
Logs Log Drains
and select Enable a log drain.
Select Amazon S3 as the Log drain service.
Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
Optional: add Traffic log filtering. If you’re draining traffic logs and don’t want client_ip and user_agent in the data, select Exclude personally identifiable information (PII).
Under Service settings, select the Bucket region where your bucket is located.
Enter your S3 Bucket name.
Enter your S3 Bucket path. We recommend using YOUR_BUCKET_NAME/logs/netlify/.
Select Verify bucket and connect.
Use the provided path to navigate to your S3 bucket’s verification file.
Copy and paste the contents of the file into the Verification token field, then select Verify.

# Edit a log drain

If you need to adjust the settings for an existing log drain, under

Logs Log Drains

, select Configure. Configuration changes become active within approximately five minutes.

To stop sending specific log data to your external monitoring provider, clear the Log types you no longer need and then save your change.

# Remove a log drain

To terminate an existing log drain configuration for a site, under

Logs Log Drains

, select Delete. All log types associated with the site’s log drain will be removed. Saved logs are accessible in your logging service provider account.

# Traffic log output

Drained site traffic logs include the following fields parsed from our CDN logs:

account_id: ID of the Netlify team that the site belongs to.
client_ip: IP address of the client. Omitted if you selected Exclude personally identifiable information (PII).
content_type: Content-Type of the request (for example, text/html).
country: country of origin for the request, formatted as an ISO 3166-1 two-letter code.
deploy_id: ID of the deploy (for example, 61153ae8b0f6a900088386e8).
duration: duration of the request in milliseconds.
firewall_rule: the Firewall traffic rule that matches the request. Can be one of default_allow, default_deny, ip_allow, ip_deny, geo_allow, geo_deny , or -. If there are no traffic rules added to a site, then firewall_rule returns -. Learn more about Firewall traffic rules.
block_reason: indicates why the request was blocked. If there are rate limiting rules applied to the site and if the rules match the request, then block_reason returns rate_limit. Learn more about Rate limiting Rules.
rate_limit:
- rule_id: ID of the rate limiting rule the request matched. Learn more about Rate limiting Rules.
[Deprecated] rule_id: ID of the rate limiting rule the request matched. This field is being deprecated and will disappear in a future release, use rate_limit.rule_id instead.
log_type: indicates the type of log. The value is traffic.
method: request method.
referrer: referrer on the request.
request_id: Netlify request ID (for example, 01FDWR77JMF2DA1CHF5YA6H07C).
request_size: size of the request in bytes.
response_size: size of the response in bytes.
site_id: ID of the site.
status_code: status code of the HTTP response.
timestamp: timestamp of the request, formatted with RFC 3339 (for example, 2021-08-24T18:54:34.831Z).
url: URL of the request.
user_agent: user-agent that made the request. Omitted if you selected Exclude personally identifiable information (PII).
waf:
- outcome: indicates the outcome of the request evaluated by Web Application Firewall (WAF). Can be one of passive, blocked, under threshold, or no match.
  - When WAF is enabled in passive mode and a request matches a WAF rule, the outcome is passive.
  - When WAF is enabled in blocking mode and a request matches enough WAF rules to surpass the anomaly threshold, then the outcome is blocked. Otherwise, the outcome is under threshold.
  - When WAF is enabled in passive or blocking mode, and a request does not match any enabled WAF rules, the outcome is no match.
- rule_id: ID of the matched Web Application Firewall rule.
- policy_id: ID of the WAF policy applied to the evaluated request. The WAF policy represents all enabled WAF rules or rulesets and any additional configuration, such as excluded paths or whether the passive or blocked mode are enabled.
- rule_set_id: ID of the ruleset applied to the evaluated request.

# Function log output

Drained function logs include the following fields parsed from our CDN logs:

account_id: ID of the Netlify team that the function belongs to.
branch: the branch of the deploy.
deploy_id: ID of the deploy (for example, 61153ae8b0f6a900088386e8).
duration: amount of time it took for AWS Lambda to execute the function.
function_name: name of the function.
function_type: type of function. The value for function logs is standard.
level: level of the log line (for example, INFO, ERROR, WARN, REPORT).
message: log message.
log_type: field indicating the type of log. All function types will have the value functions.
method: method of the request (for example, GET).
path: path of the request (for example, /.netlify/functions/your-awesome-function).
request_id: Netlify request ID (for example, 01FDWR77JMF2DA1CHF5YA6H07C).
site_id: ID of the site.
status_code: status code of the HTTP response.
timestamp: timestamp of the request, formatted with RFC 3339 (for example, 2021-08-24T18:54:34.831Z).

# Function log output limitations

Netlify’s Log Drains feature doesn’t currently support function log output for Background Functions. We recommend storing historical logs for this type of function on an external service.
Function log output is limited to 4 KB total per invocation. If a log’s output exceeds 4 KB, only the last 4 KB of the log is sent to the logging service and the log message will be truncated.

# Edge Function log output

Drained edge function logs include the following fields parsed from our CDN logs:

account_id: ID of the Netlify team that the edge function belongs to.
branch: name of the branch. This field is only present for non-production branches.
deploy_id: ID of the deploy (for example, 61153ae8b0f6a900088386e8).
function_name: name of the edge function.
function_type: type of function. The value for edge function logs is edge.
level: level of the log line (for example, INFO, ERROR, WARN, REPORT).
log_type: field indicating the type of log. All function types, including edge functions, will have the value functions.
request_id: Netlify request ID (for example, 01FDWR77JMF2DA1CHF5YA6H07C).
request_path: path of the request (for example, /log).
site_id: ID of the site.
timestamp: timestamp of the request, formatted with RFC 3339 (for example, 2021-08-24T18:54:34.831Z).

Log messages will appear in the content field for your logging service.

# Deploy log output

Drained deploy logs include the following fields parsed from our internal build logs:

account_id: ID of the Netlify team that the deploy belongs to.
deploy_id: ID of the deploy (for example, 61153ae8b0f6a900088386e8).
deploy_section: section of the deploy process (for example, Initializing, Building, Deploying, Cleanup, Post-Processing).
level: level of the log line (for example, INFO, ERROR, WARN, REPORT).
log_type: field indicating the type of log. The value is deploys.
message: log message.
site_id: ID of the site.
timestamp: timestamp of the log line, formatted with RFC 3339 (for example, 2021-08-24T18:54:34.831Z).

# WAF log output

Drained WAF logs include the following fields:

site_id: ID of the site.
deploy_id: ID of the deploy (for example, 61153ae8b0f6a900088386e8).
account_id: ID of the Netlify team that the site belongs to.
policy_id: ID of the evaluated WAF policy, which defines the WAF rules to be evaluated.
timestamp: timestamp of the request in Unix epoch nanosecond format (for example, 1725353586606141655).
action:
- type: indicates the final action taken for the request, can be one of LOG or BLOCK.
request:
- id: Netlify request ID (for example, 01FDWR77JMF2DA1CHF5YA6H07C).
- method: request method.
- protocol: request HTTP protocol, can be one of HTTPS or HTTP.
- url: URL of the request.
- connection_ip: The IP used to create the connection to Netlify. Omitted if you selected Exclude personally identifiable information (PII).
- client_ip: IP of the original client if the request originates from a known source (such as Cloudfront). In those cases, the connection_ip will refer to the known source's outgoing IP, and client_ip refers to the request handled by known source. If the request does not come from a known source, client_ip and connection_ip are the same. Omitted if you selected Exclude personally identifiable information (PII).
- location:
  - country: full name of the country of origin for the request.
- size: size of the request in bytes.
response:
- status: HTTP status of the response (for example, 200).
- size: size of the response in bytes.
rule_sets: list with information about each ruleset evaluated for the request. Each item on the list has the following format:
- id: ID of the ruleset (for now always crs-basic).
- version: version of the ruleset (for example, v1.0.0).
- mode: indicates how the ruleset was evaluated, can be one of passive or block.
- outcome: indicates the outcome of the request evaluated by Web Application Firewall (WAF). Can be one of under_threshold, blocked, passive or no_match.
  - When the request's calculated score was lower than the threshold needed to trigger the set action, the outcome is under_threshold, and no block was applied.
  - When the request was blocked because it was over the anomaly threshold, the outcome is blocked.
  - When the request is over the anomaly threshold but the ruleset is set to passive mode, the outcome is passive.
  - When the request matched no rules, the outcome is no_match.
- anomaly_score: the anomaly score calculated for the overall request.
- anomaly_threshold: the anomaly threshold set for the overall request.
- anomaly_score_per_category: the anomaly score calculated for each rule category of the evaluated request.
- anomaly_threshold_per_category: the anomaly threshold set for each rule category (only set if defined by the user).
- matched_rules: list with information about the rules that matched for this ruleset. Each item on the list has the following format:
  - rule_id: ID of the rule.
  - labels: list of labels for the matched rule, obtained from the CRS definition (for example, ["platform-multi", "attack-protocol", "paranoia-level/1"]).
  - metadata: list with information about the rule matching logic and the input provided from the request. Each item on the list has the following format:
    - matcher_type: type of the matcher being used on the rule, each one matching on a different type of input. Can be one of header (a single HEADER-VALUE pair), cookie (full value of the cookie header of the request), path (request path), method (request method), query (decoded request query), protocol (request protocol), uri (decoded request URI), uri_raw (encoded request URI), header_names (names of the request headers), cookie_names (names of cookies - the key on each key-value pair), query_string (encoded request query), query_names (names of the request query - the key on each key-value pair) or request_line (HTTP plaintext representation of the request line, for example GET /background.png HTTP/1.0.)
    - match_on: textual representation of the rule matcher being evaluated (for example, KEY Host, VALUE EQUALS 0).
    - value: input value matched for this rule matcher.
    - error: if there was an error evaluating the rule (only set if an error occurred).

Last updated: October 28, 2024

Did you find this doc useful?

Your feedback helps us improve our docs.

Log Drains

# Configure a log drain

# Datadog

# New Relic

# Axiom

# Azure Monitor

# Sumo Logic

# Configure your HTTP Logs and Metrics Source in Sumo Logic

# Set up the log drain in the Netlify UI

# Splunk Observability Cloud

# Logflare