The record of what happened.

• The request log, at the edge

  Who asked for a page or a route, when, and what status code came back.

  Handled by

  CustomHosted

  Written for every request, automatically, before your own code ever runs.

• Your app's own output

  A caught error, a warning, a line your own code decided to write down.

  Handled by

  You

  Only exists if your code writes it. This page cannot show you output your app never produced.

• The change record

  Who deployed, who restored a backup, who set a secret.

  Handled by

  CustomHosted

  A record of an action taken on your account, not of a request or a line your app printed.

1. 1

   Your code writes a line

   To standard output, the same place a program has always written a line meant to be read later.

   You

2. 2

   A collector picks it up off the box

   Running on the same instance, watching that output as it is written — not waiting for the process to end.

   The collector

3. 3

   It lands in a store outside the box

   So the line survives a restart, a crash, or the box itself being replaced. A log kept only on the box dies with it.

   CustomHosted

4. 4

   It is searchable by time window

   Filtered to when something happened, not read as one long, unbroken file.

   CustomHosted

1. 1

   An incident note arrives, or you write in yourself

   Monitoring fixes most of what it watches for on its own. As it puts it: "no one, unless it recurs — it goes in the log, not a message to you". A note only reaches you once a person has looked at it.

2. 2

   You have a timestamp

   The note names roughly when it happened. That window is the key that unlocks every record below.

3. 3

   The request log narrows it to the request

   Filtered to that window, the request log shows which request or requests were actually involved.

4. 4

   Your app's own output says what the code did

   Application output from the same window says what your code decided to do. That only exists if your code wrote something down.

5. 5

   The deploy record says what changed just before

   If the timing lines up with a recent deploy, the change record shows exactly what shipped and when.

• It is redacted from logs

  A build or deploy log shows that a variable was set, never what it was set to — for a person reading the log, or an agent reading the build output.

• A request body, by default

  What a visitor typed or posted is not written down. Only that a request happened, and what came back.

• A visitor's identity, beyond what's already disclosed

  Nothing here goes further than the analytics already named for you. See Privacy for the binding text.

• The quote form never writes your message to a log

  The function behind this site's own quote form has no logging call in it at all. What you type in the message field is never written down anywhere.

• Only the platform’s own invocation record exists

  Start, end, how long it ran, and whether it succeeded. Kept for the same window as the request log above.

• Every deploy leaves a build record

  What ran, whether it passed its checks, and when. The same build/deploy record class this page names above.

• No console to log into

  There is no dashboard to click through. An extract is a request, sent through the quote channel, not a click.

• Retention is a window, not an archive

  Every record class above ages out on its own schedule. Nothing here is kept forever, and nothing here is a permanent record.

• A log is not a backup

  A log is a record of what happened. It is not a copy of your data, and it cannot restore anything that is gone. See Recovery for the rest of it.

• No request tracing or per-transaction profiling

  A single request's full path through every layer it touched is not rebuilt automatically. This page's own request log narrows a window. It does not trace one transaction end to end.

• A line your code never wrote cannot be recovered afterwards

  If your app did not write it down, it does not exist later. No request log, deploy record, or change record can recreate a line your own code chose not to write.

• A stack trace with a timestamp

  Already a brief. Paste it, say when it happened, and say what you were doing — the change starts from there.

• A recurring line in your app's own output

  The same warning or error showing up over and over is worth briefing as a fix, not just watching.

• A request log pattern that needs a code change to fix

  A narrowed-down request log can show what's happening. Only a change to the application code can stop it happening again.

Every one of those ships the same way — Agentic iteration — CodeHerder ($25/mo):

1. 1

   A routine scan flags a dependency

   The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.

2. 2

   It's triaged as application-level, not infrastructure

   A library your own code imports isn't ours to patch silently — it can change how the app behaves.

3. 3

   Briefed as a change

   Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.

4. 4

   An agent opens the pull request

   The upgrade lands as a real pull request against the repository, with the test suite run against it.

5. 5

   A human reviews and merges

   Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.

6. 6

   It ships through the same pipeline

   The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.

7. 7

   You're told it's done

   A note confirming what changed and that it merged, in the same shape as every other note on this site.

1. 01Where do my app's logs actually go?

   A collector picks up your code's own output off the instance. It lands outside the box, for the window named in the retention table above. Nothing lives only on the box.

2. 02Can I get a live tail of my logs?

   Not through a console — there is none. Ask through the quote channel for an extract covering a window, and we pull it.

3. 03How do I find out why my site returned an error at a specific time?

   Follow the walk above. The timestamp narrows the request log to the request. Your app's own output says what the code did. The deploy record shows anything that shipped just before.

4. 04Can the CodeHerder agent read our logs?

   No. It reads your application code to brief and open a pull request. It never opens a connection to a log store or a live system.

5. 05Is a log the same thing as a backup?

   No. A log is a record of what happened. A backup is a copy of your data. See Recovery for what a backup actually restores.

6. 06How long are logs kept?

   It depends on the record class — see the retention table above. Every class ages out on a window; none of them is kept forever.

7. 07Will a secret value ever show up in a log?

   A build or deploy log shows that a variable was set, never what it was set to — for a person reading the log, or an agent reading the build output.

8. 08Who can read our logs?

   See Access for the full matrix. Your team can request an extract. Our engineers can read one to operate your stack. The deploy pipeline and the CodeHerder agent cannot.