Skip to main content
Flarehawk handles the full Fastly logging setup for you. You provide a Fastly API token; Flarehawk discovers your services, provisions HTTPS real-time logging endpoints, and streams events into detection and investigation workflows. You do not need to configure logging destinations, log formats, or service versions manually in the Fastly control panel.
The Fastly connector is in beta and is available from Manage → Connections → Add Connection. If you want help validating a production service, contact [email protected] or use live chat in the dashboard.

​
How log delivery works

Flarehawk uses Fastly’s HTTPS real-time logging API to push NDJSON events to Flarehawk ingest as traffic hits the edge: Ingest authentication uses a per-connection bearer token sent in the Authorization header on each log delivery. The token is not embedded in the logging endpoint URL.

​
Prerequisites

  • An active Flarehawk organization. See the quickstart if you have not signed up yet.
  • A Fastly account with at least one active service.
  • Permission to create a Fastly user API token with service configuration and logging read/write access.
  • For WAF logs: Next-Gen WAF (Signal Sciences) deployed on the edge for the services you select.

​
Create the Fastly connection

1

Open the Connections page

In the Flarehawk dashboard, go to Manage → Connections and click Add Connection. Select Fastly.
2

Create a Fastly API token

Click Open Fastly API tokens in the wizard (or go to Fastly API tokens) and create a user token with:
  • Service configuration — read and write
  • Logging — read and write
Copy the token immediately — Fastly only displays it once.
3

Paste the token and test

Paste the API token into the Flarehawk wizard and click Test connection. Flarehawk validates the token against the Fastly API and reports how many services are available.
4

Select services

Flarehawk lists every Fastly service your token can access. All services are selected by default — uncheck any you do not want to monitor.
5

Select log sources

Choose which telemetry to stream:
  • HTTP Request Logs — available on any active service.
  • WAF Security Logs — requires Next-Gen WAF on the service; only inspected requests are logged.
You can enable one or both.
6

Review and create

Confirm the connection name, service count, and log sources, then click Create connection. Flarehawk provisions logging endpoints on each selected service and activates the updated service version.
7

Verify ingestion

After provisioning completes, generate traffic through your Fastly services. Within a few minutes, events appear under Monitor → Logs and Monitor → Analytics. Connection status should show Active with a recent last-seen timestamp.

​
What Flarehawk provisions automatically

After you create the connection, Flarehawk configures the following on each selected Fastly service — no manual Fastly UI work required:
Flarehawk creates or updates endpoints named Flarehawk_HTTP_<service> and Flarehawk_WAF_<service> pointing at https://ingest.flarehawk.com/fastly/.... Endpoints use NDJSON (application/x-ndjson) with JSON format version 2.
If the active service version is locked, Flarehawk clones it, applies logging changes on the editable version, and activates the new version. When endpoints already match the desired configuration, Flarehawk skips version churn.
For WAF logs, Flarehawk creates a response condition (flarehawk_waf_inspected) so only requests with Next-Gen WAF signal headers are logged.
Fastly verifies HTTPS logging destinations via /.well-known/fastly/logging/challenge. Flarehawk serves this challenge on ingest automatically — you do not configure it.

​
Sync and updates

From the connection detail page, click Sync to:
  • Re-provision logging endpoints if they were changed or removed in Fastly
  • Apply log-source changes after you update enabled datasets
  • Repair failed endpoint rows reported in the connection status
Flarehawk scopes assets by organization. A Fastly service already connected in another Flarehawk organization cannot be hijacked — the wizard blocks duplicate provisioning during precheck.

​
Optional exact-IP response onboarding

Incident Response V2 can propose approval-only, 24-hour exact-IP blocks through a preconfigured Fastly ACL. This capability is off by default and supports VCL CDN services only; Fastly Compute services remain manual. For each opted-in service, create a dedicated ACL whose name starts with flarehawk_, attach it to the active service version, and enforce it in vcl_recv. At the top level of that subroutine, place # flarehawk-response-acl:<ACL_ID> immediately before a simple positive client.ip ~ <ACL_NAME> condition whose only action is a 403 error/synthetic response. Negated, compound, or nested conditions are rejected. In the connection’s optional Response ACL bindings field, supply the exact service ID, ACL ID, and ACL name. Testing the connection verifies the global-write token, active VCL service, attached ACL, ownership marker, and blocking behavior before Flarehawk writes a nonsecret readiness marker. Only one exact public IPv4 or IPv6 address is accepted. CIDR ranges, ASNs, countries, and arbitrary expressions are rejected. Applying and rolling back always require explicit approval, and rollback removes only an entry that the same Flarehawk action created.

​
Troubleshooting

​
Connection shows an error after create

  • Confirm the API token still has service configuration and logging write access.
  • Check whether the service’s active version can be cloned and activated (some accounts restrict version edits).
  • Open the connection detail page and click Sync to retry failed datasets.

​
HTTP logs appear but WAF logs do not

  • Confirm Next-Gen WAF (Signal Sciences) is deployed on the edge for that service.
  • WAF logs only include requests the WAF inspected (X-SigSci-Tags present). Uninspected traffic is intentionally excluded.

​
Logs stop after a Fastly change

  • If someone edited or deleted Flarehawk logging endpoints in Fastly, run Sync on the connection to repair them.
  • If the API token was rotated or revoked, update credentials on the connection (or recreate the connection with a new token).

​
Revoking access

Revoke the API token in the Fastly control panel under Account → API tokens. Flarehawk will detect invalid credentials on the next sync and pause provisioning. You can also delete the connection from Flarehawk, which stops new log delivery for that connection’s ingest token.

​
Next steps

Detection rules

Learn which rules Flarehawk applies to Fastly HTTP and WAF events.

Logs explorer

Search raw Fastly events and pivot into incidents.