Understanding Ordinary Events :: Ordinary Blog Understanding Ordinary Events<br>2026-06-23sean 🦋 🐘 🏔️<br>#events  #logging  #tracing  One major advantage of Ordinary’s architecture is that it makes it possible to derive insights about behavior and performance without a ton of additional time spent configuring and tuning instrumentation yourself.When you use Ordinary, the facilities for request/response logging, as well as inter-service communication are wired up immediately for templates, actions, proxies, integrations and storage, with additional facilities for hooking into the core events system in cases where you BYO code (i.e. actions or client JavaScript).In this post we’re going to begin walking through how this is accomplished and what it enables for folks who want to build on Ordinary.Outline#<br>configurationstored | stdio | journaldfine-tuninglevel | sizes | headers | ip-addressessystem-architectureappslogfilesttl-&-rotationordinaryd-api | ordinary-clicustom-eventsactionsclientevents | pxevent-structurequerying-eventsread | searchconclusion | futureConfiguration#<br>As a host running ordinaryd you have a few exporters/formatters at your disposal:--stored-logs (the primary focus of this post)--stdio-logs (--stdio-logs-fmt: json (default), concise, pretty)--journald-logs (queryable with journalctl: only available for Linux/systemd)Stored#<br>If you’re looking for Ordinary to be your one-stop-shop for hosting (either for yourself or people you’re serving) and don’t want to run separate systems for ingesting and managing events, --stored-logs is gonna be your go-to option. With --stored-logs each domain gets its own logs directory where ordinaryd runs and allows for any tenant to access their logs via the ordinary CLI with the same credentials they use to publish/deploy their app.Stdio#<br>Stdio logs can be useful if you already have an existing log management solution1 that can process either JSON formatted logs or the default format from tracing. There is a pretty format mode as well, but it is primarily useful for debugging and not recommended to run in production.# json<br>{"ts":"2026-06-24T19:22:59.732547Z","lvl":"INFO","spn":{"app":{"_":0,"domain":"ordinary.blog","host":"localhost:4433","path":"/","rid":"9f6c42a4-d4f6-45b4-a655-9db2e7dbc07d"}},"fld":{"headers":{"accept-encoding":"gzip, deflate"},"msg":"req","method":"GET","version":"HTTP/1.1"}}

# concise<br>2026-06-24T19:19:01.697827Z INFO app{domain=ordinary.blog host=localhost:4433 rid=57166ed7-80c6-4aa7-82f2-1c83bc77151b path=/}: req version=HTTP/1.1 method=GET headers={"accept-encoding": "gzip, deflate"}

# pretty<br>2026-06-24T19:32:35.834964Z INFO ordinary_utils::middleware: req, version: HTTP/1.1, method: GET, headers: {"accept-encoding": "gzip, deflate"}<br>at core/shared/utils/src/middleware.rs:201<br>in ordinary_utils::middleware::app with domain: ordinary.blog, host: localhost:4433, rid: 59a42593-a3b4-429b-8b9f-7f15bec775fb, path: /

Journald#<br>Journald logging is primarily useful if you’re already heavily integrated with the systemd init system and don’t want to introduce an additional dimension for log management.Fine Tuning#<br>Different use cases require different verbosity levels, and properties included/ignored, so across all the logging modes there are some shared configuration options:--log-level: trace | debug | info (default) | warn | error--log-sizes: true | false (default)--log-headers: true | false (default)--log-ips: true | false (default)Level#<br>The --log-level flag tells ordinaryd at what minimum verbosity level should events be considered. If you’re only interested in seeing warnings and errors, you can pass --log-level warn but if you’d like to see request/response logs at the info level you can omit the flag and accept the default.Sizes#<br>Primarily geared toward functions of the storage service, the --log-sizes flag controls whether things like item/asset/content sizes are recorded on insert/delete.Headers#<br>Off by default, --log-headers decides whether request and response headers are logged. This flag affects the req/res headers for app, proxy and middleware endpoints.Sensitive headers2 are swapped for the string redacted by default; a companion flag --redacted-header-hash allows hosts to select a hashing algorithm to hash and truncate (6 bytes, base64 encoded) the sensitive values. The current hashing algorithm options are blake2 and blake33.IP Addresses#<br>Same as --log-headers, --log-ips is off by default. Depending on your deployment scenario you may or may not want to log IP addresses – if ordinaryd is a host’s primary entrypoint and an important part of keeping the service online includes monitoring for problematic behavior, associating an IP address or group of addresses with bad traffic is a valid use case.System Architecture#<br>Looking primarily at the --stored-logs scenario – as ordinaryd doesn’t own much after export in the --stdio-logs and --journald-logs cases – the goal is to stay as simple as reasonably possible within ordinaryd’s domain...