OolvayDocsThreat Protection
How Oolvay rate-limits, screens for bots, and blocks attack traffic using Arcjet, and how to protect your own routes and server actions.
Logging
Configure structured application logging, choose a transport provider, and understand how log levels, sampling, and redaction work together.
Observability is the practice of understanding what your application is doing in production. When a user reports a problem, a payment fails, or a page suddenly becomes slow, observability tools help you answer three questions:
Oolvay separates observability into two complementary layers:
| Layer | Purpose | Providers |
|---|---|---|
| Logging | Records application activity and events | Console, Better Stack, Axiom |
| Error tracking | Captures crashes, exceptions, and performance issues | Sentry |
All observability integrations are optional. No telemetry is collected unless you explicitly configure a provider.
In this section, you’ll learn how to configure logging and error tracking in Oolvay, when console logging is sufficient, when centralized logging platforms such as Better Stack or Axiom make sense, and where Sentry fits into your operational workflow.
Logging creates a record of what your application is doing.
Typical examples include:
By default, Oolvay produces structured JSON logs that can be read directly from your hosting platform’s log viewer.
Console logging writes logs only to your application’s standard output.
This approach is ideal for:
It requires no additional services and works immediately.
As applications grow, searching logs across multiple deployments and environments becomes increasingly difficult.
Log transportation forwards logs from your application to a dedicated log management platform such as Better Stack or Axiom. These platforms provide centralized storage, advanced search, filtering, dashboards, retention policies, and collaboration features.
Consider log transportation if:
0 / 2,000 characters
Threat Protection
How Oolvay rate-limits, screens for bots, and blocks attack traffic using Arcjet, and how to protect your own routes and server actions.
Logging
Configure structured application logging, choose a transport provider, and understand how log levels, sampling, and redaction work together.
For many early-stage products, console logging remains sufficient until traffic and operational complexity increase.
Logging records everything. Error tracking focuses on failures.
Sentry captures:
When an error occurs, Sentry collects the stack trace, request context, and diagnostic information needed to investigate the issue.
A useful way to think about the difference:
Logs are passive. They wait for you to search and investigate them.
Sentry is active. When something important breaks, it alerts you immediately, group related errors together, and show you the stack trace and context needed to diagnose the issue.
Not every log entry belongs in Sentry. Most logs describe normal application activity, while Sentry is intended for events that require immediate attention or intervention.
Most production applications benefit from both.
If you are launching a new product, console logging is usually enough to get started. As your application gains users and revenue, centralized logging and error tracking become increasingly valuable.
There is no universally correct observability setup.
A solo founder launching an MVP has very different needs from a team operating a production application with thousands of users.
As a general guideline:
| Stage | Recommended setup |
|---|---|
| MVP or internal tool | Console logging |
| Early-stage SaaS | Console logging + Sentry |
| Growing startup | Better Stack or Axiom + Sentry |
| Multi-developer production application | Better Stack or Axiom + Sentry |
You can start with console logging and add centralized logging or error tracking later without changing application code.
Observability in Oolvay is intentionally modular. You can start with console logging, add centralized log management as your application grows, and enable error tracking independently whenever you need it.
Most projects begin with console logging and add additional tooling only when operational complexity justifies it. Because all observability integrations are optional, you can adopt them incrementally without changing your application’s business logic.
The guides in this section explain how to configure each provider, what problems it solves, and when it makes sense to use it.