How-to

HTTP Methods and Required Logpush Fields

What the HTTP methods card tells you, and how to fix the "(no method)" bar by adding ClientRequestMethod to your Logpush job.

3 min readLast updated 26 April 2026

Jump to section

What the HTTP methods card shows
Why this matters
Fixing "(no method)"
The full required-fields list

What the HTTP methods card shows

On every Path detail page, the HTTP methods breakdown shows how requests to that path split by method: GET, POST, PUT, etc. Colour-coded:

Green — read-only (GET, HEAD, OPTIONS)
Amber — mutating (POST, PUT, PATCH, DELETE)
Red — (no method) — Logpush didn't supply a method for those requests

Why this matters

Different attacks prefer different methods. Some real-world patterns:

Gift-card enumeration via COBilling-RedeemGiftCertificate — high POST volume from residential IPs. Legitimate gift-card redemptions are rare and evenly distributed; a burst of POSTs from 20 different ASNs in 10 minutes is almost always enumeration.
Password-reset email spam / account enumeration — mostly POST on Account-PasswordReset from distributed residential IPs + datacentre egress. See Account-PasswordReset abuse patterns.
Form-probing before an actual attack — scrapers load the form (GET) to extract the CSRF token template before submitting (POST). A sudden shift from mostly-GET to mostly-POST on a prescribed endpoint can precede active exploitation.
Scanning / fuzzing — high GET volume on endpoints that shouldn't be GET-accessible. Classic directory enumeration or API probing.

Fixing "(no method)"

If the HTTP methods card on a path shows a large red (no method) bar — especially 100% — it means the Cloudflare Logpush job for your source isn't shipping the ClientRequestMethod field to Blankitt.

How to fix:

Open your Cloudflare dashboard → select your zone → Analytics & Logs → Logpush
Edit the Logpush job that points at Blankitt's ingest URL
In the field selection, ensure ClientRequestMethod is ticked
Save the job

The next Logpush batch (≤ 5 minutes) will start including the method. Historical data from before the fix will continue to show (no method) — that portion fades out naturally as it ages out of the 90-day Analytics Engine retention window.

The full required-fields list

Logpush is opt-in per field. The following fields should all be selected on your job config; missing any of them causes specific Edge features to degrade silently.

Cloudflare field	What breaks without it
`EdgeStartTimestamp`	Ingest fails entirely — this is required
`ClientIP`	IPs page, Unique IPs column, forensic IP-discovery
`ClientASN`	Offenders page, asn_spike and most other detectors
`ClientCountry`	Country-scoped baselines, WorldMap
`ClientRequestPath` / `ClientRequestURI`	Paths page, path_spike detector
`ClientRequestMethod`	HTTP methods card (this article)
`ClientRequestUserAgent`	UA families, ua_rotation detector
`EdgeResponseStatus`	Status classes, 499_rate detector
`EdgeResponseBytes`	Bytes columns everywhere
`OriginResponseDurationMs`	`origin_latency_spike` detector, origin-latency diagnostics. SFCC renamed this from the legacy `OriginResponseTime` in the current catalogue; only the new name is accepted from 2026-04-22.
`CacheCacheStatus`	Cache breakdown, cache_bypass detector
`EdgeColoCode`	Data Centres panel
`BotScore` (SFCC eCDN only)	bot_score detector
`ClientSSLProtocol`	tls_weak_protocol detector
`SecurityActions` (SFCC) / `FirewallMatchesActions` (raw Cloudflare)	challenge_solving detector

If a detector or UI panel isn't populating as expected, the first thing to check is whether its required field is in the Logpush config.