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

Select your external monitoring provider:

Datadog

1. For your selected site, go to Logs > Log Drains and select Enable a log drain.
2. Select Datadog as the Log drain service.
3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
4. 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).
5. Under Service settings, select the Region where your Datadog site is located.
6. 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.
7. 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

8. Select Connect.

New Relic

1. For your selected site, go to Logs > Log Drains and select Enable a log drain.
2. Select New Relic as the Log drain service.
3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
4. 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).
5. Under Service settings, select the Region that applies to your New Relic account.
6. Enter a License API key, also called INGEST-LICENSE, for your New Relic account. Verify that you’re entering your License API key and not your License API key ID or user key.
7. Optional: to add a tag for your log drain, under Tags, enter the key and value. Then select Add tag. Any tags you add become query parameters in log drain requests to New Relic.

Example tags for New Relic:

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

For guided help on optimizing your New Relic dashboard for your site’s logs, install the Netlify Logs quickstart on New Relic.

8. Select Connect.

Axiom

To configure a log drain that sends your site logs to Axiom:

1. On Axiom, go to Integrations.
2. Install Netlify’s Axiom integration, which opens a prompt to authorize the Axiom app to access Netlify on your behalf.
3. Once installed, you’re redirected to configure your Netlify integration on Axiom. Copy the Axiom integration token.
4. On Netlify, for your chosen site, go to Logs > Log Drains and select Enable a log drain.
5. Select Axiom as the Log drain service.
6. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
7. 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).
8. Under Service settings, paste the Integration token copied from Axiom.
9. Confirm with Connect.

For an overview of reviewing your logs on Axiom, check out Axiom’s Netlify Integration docs.

Azure Monitor

To send your site’s log drains to Azure Monitor through the Netlify UI:

1. On Azure Monitor, from your log analytics workspace, go to Settings > Agents. Under the Log Analytics Agent Instructions dropdown, you’ll find the Workspace ID and Primary key you’ll need to enter into the Netlify UI.
2. On Netlify, for your chosen site, go to Logs > Log Drains. If this is your first log drain for your site, select Enable a log drain.
3. Select Azure as the Log drain service.
4. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
5. 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).
6. Under Service settings, enter your Azure Workspace ID and Primary key.
7. Confirm with Connect.

For an overview of reviewing your logs on Azure, check out Azure’s Analytics workspace docs.

Sumo Logic

To configure a log drain that sends logs to your Sumo Logic account, you need to:

1. Configure your HTTP Logs and Metrics Source in Sumo Logic
2. Set up the log drain in the Netlify UI

Configure your HTTP Logs and Metrics Source in Sumo Logic

1. If you haven’t already, create a hosted collector to collect your data in Sumo Logic.

2. In the Sumo Logic web app, add and configure your HTTP Logs and Metrics Source using Sumo Logic’s docs.

3. Ensure that you copy your HTTP Source Address to use in the Netlify UI.

Set up the log drain in the Netlify UI

For security, Netlify hides the full HTTP Source Address in the Netlify UI. After you configure your log drain, only the base URL is visible in the Netlify UI.

1. On Netlify, for your selected site, go to Logs > Log Drains and select Enable a log drain.
2. Select Sumo Logic as the Log drain service.
3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
4. 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).
5. Under Service settings, fill in the Full URL field using the HTTP Source Address you copied from Sumo Logic.
6. Select Connect.

Splunk Observability Cloud

1. For your selected site, go to Logs > Log Drains and select Enable a log drain.
2. Select Splunk Observability Cloud as the Log drain service.
3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
4. 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).
5. Under Service settings, enter the Realm from your Splunk Observability Cloud profile.
6. Enter the Access Token from your Splunk Observability Cloud settings.
7. Select Connect.

Logflare

1. For your selected site, go to Logs > Log Drains and select Enable a log drain.
2. Select Logflare as the Log drain service.
3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
4. 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).
5. Under Service settings, enter your Logflare Ingest API key.
6. To specify where you want your logs to go, enter the Logflare Source ID for your logs.
7. Select Connect.

Amazon S3

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

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

Create an Amazon S3 bucket and set up a bucket policy

1. 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.

2. Go to your bucket’s Permissions and under Bucket policy select Edit.
3. Copy and paste the following bucket policy, replacing YOUR_BUCKET_NAME with the name of your Amazon S3 bucket:

JSON

{
  "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"
        }
      }
    }
  ]
}

4. 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

1. For your selected site, go to Logs > Log Drains and select Enable a log drain.

2. Select Amazon S3 as the Log drain service.

3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.

4. 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).

5. Under Service settings, select the Bucket region where your bucket is located.

6. Enter your S3 Bucket name.

7. Enter your S3 Bucket path. We recommend using YOUR_BUCKET_NAME/logs/netlify/.

8. Select Verify bucket and connect.

   

9. Use the provided path to navigate to your S3 bucket’s verification file.

10. Copy and paste the contents of the file into the Verification token field, then select Verify.

General HTTP endpoint

Netlify’s General HTTP endpoint support allows you to set up a custom log drain with any external monitoring provider that accepts log drain requests in JSON or NDJSON format.

To set up a custom log drain, you must provide a full URL of your external monitoring provider’s endpoint. Depending on your external monitoring provider, you can enter your API key as a query parameter in your endpoint or you can enter an Authorization header in the Netlify UI.

For example, this URL includes an API key and a tag as query parameters:

http://YOUR_ENDPOINT_RESOURCE_PATH?api-key=YOUR_API_KEY&environment=production

For security, Netlify hides the full endpoint in the Netlify UI. After you configure your log drain, only the base URL is visible in the Netlify UI.

1. For your selected site, go to Logs > Log Drains and select Enable a log drain.
2. Select General HTTP endpoint as the Log drain service.
3. Select the Log types to drain. You can drain your site’s traffic logs, function logs, edge function logs, and deploy logs.
4. 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).
5. Under Service settings, enter the Full URL for your endpoint, including any optional tags as query parameters. Depending on your external monitoring provider, enter your API key as a query parameter in your endpoint or under Authorization header.
6. Select the Log Drain Format that your endpoint accepts.
7. Select Connect.

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 processing the request and sending the response, 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 (for example, regular for a synchronous function or background for a background function). Note this value may be standard for functions deployed before November 5, 2024, independent of the underlying type.
• 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).