See the HTTP requests your app is serving

When an app is published on a DedNets hostname, every request to it passes through our edge. You can ask us to keep a short record of those requests for one app, so you can answer the questions a “it’s up” badge never can: why did that webhook get a 502, is anything reaching my app at all, what is hammering this URL. (Since v0.11.2.)

It is off for every app until you turn it on, and turning it off deletes everything we kept.

Turn it on

Open Services, pick the app, and find the Request log block in its detail pane. Flip the switch and you get a dialog listing exactly what we would store. Read it - it is short, and it is the point - then choose Start recording.

The switch only appears for apps we can actually see: an HTTP app with at least one hostname served by the DedNets edge. For anything else the block says so rather than offering a switch that could not do anything.

What gets stored

One row per request, on DedNets servers:

• the hostname, method and path that was asked for
• the status we answered with, how long it took, and the bytes we sent
• the visitor’s network - the first part of their IP address, like 203.0.113.0/24, never the whole one
• the browser’s user agent
• the DedNets account, on requests your sign-in gate let through

Two things worth saying plainly:

• Anyone who can sign in to your DedNets account can read these rows. They are not separately protected, and there is no way to share only them.
• Paths carry secrets more often than people expect - a password-reset link, a signed download URL, a filename. Those land in this log too.

What is never stored

There is no place for it, so it cannot end up there by accident:

• the query string (everything after ?)
• request or response bodies
• cookies, Authorization, or any other header
• the Referer - it is a full URL from another site, query string included
• the visitor’s full IP address, which is cut down to a network prefix before it is written anywhere

Reading the list

Rows arrive live while you watch - the pill by the heading says live. If the connection drops we fall back to polling and the pill says polling, so you always know which feed you are looking at.

Scroll down and new rows stop jumping in under your cursor: they collect behind an “N new” button until you are ready. Filter by status family (2xx, 3xx, 4xx, 5xx) or by method; the filters are applied by the console, so the count at the bottom is the truth about your filter and not just about the page.

Beside the status you will sometimes see a word, because a status code alone cannot say what happened at our edge:

Word	Meaning
sign-in	your app’s DedNets login gate asked the visitor to sign in
denied	the visitor is signed in but is not on the app’s allow list
challenged	the browser check stopped what looked like a bot
no answer	we could not reach your app (the 502 your visitor saw)
upgraded	a websocket or other protocol upgrade
taken down	the hostname is suspended

What is not in the list

Only requests through the DedNets edge are recorded, with one exception below. These paths never touch it, so nothing about them can appear:

• a custom domain you serve from your own entrypoint host
• a gateway port on your own hardware
• a proxy port between two of your hosts
• any direct, hole-punched connection

Proxy hosts on your gateway (since v0.14.0)

A proxy host is served by your gateway’s own web server, so the requests it answers never pass our edge. Once you turn the log on for such an app, the gateway records them itself - the same fields, redacted the same way, on the machine - and sends them to the Console in small batches. The block then reads “Recorded at our edge and on ”, every row says which of the two answered it, and you can filter by that. The rows land in the same list, with the same 24-hour retention, and turning the log off also deletes what the gateway still holds.

How long it is kept

24 hours, and the newest 5,000 requests for that app - whichever runs out first. Older rows are deleted automatically, and there is no setting to keep them longer.

If your app is hit hard enough that we cannot record everything, the panel tells you how many requests went unrecorded rather than letting the gap look like a quiet moment.

Turn it off

Flip the switch back. This deletes every row we have stored for that app, in the same click - there is no copy and no undo - and any live view of it stops immediately. Turning it back on later starts from an empty list, and asks you to read the notice again.

Removing or re-publishing the app has the same effect: a fresh export always starts with recording off and nothing stored.

Where it is not

There is deliberately no API-token, CLI or MCP access to request logs. A machine credential cannot read them, by design; they are readable only from the Console, signed in as the account that owns the app.