Skip to main content
When something breaks in production, logs are usually the fastest way to find out why. Hiveku streams both deployment logs (what happened during build and release) and runtime logs (console output from your running functions).

​
Two Kinds of Logs

​
Runtime Logs

Runtime logs come from your Lambda functions as they handle requests — API routes, server components, scheduled jobs.
1

Open the Hosting page

In your project, click Hosting in the sidebar.
2

Scroll to Runtime Logs

The Runtime Logs section is near the bottom of the page.
3

Pick an environment

Choose production, staging, or development — each environment has its own log stream.
4

Set a time range

Pick one of the presets or a custom range:
  • Last 60 minutes
  • Last 6 hours
  • Last 24 hours
  • Custom range
5

Set a limit

100, 500, or 1000 most recent entries. Higher limits take longer to load.
6

Read the output

Each log line includes timestamp, Lambda function name, and the message. Click a function name to filter to only that function’s logs.
Static sites (pure S3/CloudFront deployments) don’t have runtime logs — there’s nothing executing server-side. You’ll see “Not applicable” for these projects. To get runtime logs, you need server-rendered or API routes.

​
Deployment Logs

Deployment logs are separate — they show what happened during the build and release.
1

Open Deployment History

Go to Settings > Deployment History.
2

Expand a deployment

Click any deployment to expand its details. You’ll see the build log inline — npm install, next build, release steps, and any errors.
3

Search within logs

Use Cmd+F (Ctrl+F on Windows) to search the expanded log for error messages or specific output.

​
What Gets Logged

console.log is stripped in production for performance and to avoid leaking sensitive data. Use console.warn or console.error for anything you want to see in prod. If you need general-purpose telemetry, send to a dedicated observability tool rather than relying on console.log.

​
Useful Patterns

​
Tag logs for filtering

Prefix messages so you can search by area of your app:
Then filter by [payment] in the log viewer.

​
Log errors as Error objects, not strings

​
Include structured context

Structured objects are easier to scan and grep than freeform strings.

​
Verify Logs Are Flowing

1

Add a log line

In a Lambda function (API route or server action), add:
2

Deploy

Push the change through your normal deploy flow.
3

Trigger the function

Call the API route or navigate to the page that runs it.
4

Check Runtime Logs

Open the Hosting page and scroll to Runtime Logs. Your [test-log] message should appear within a minute.
See the deployments reference for more on how builds and releases work.

​
Troubleshooting

Three common causes: (1) the project is a static site — check Hosting type at the top of the page; (2) the function hasn’t been invoked in the selected time window — extend the range or trigger it; (3) a filter is applied — clear the function filter and reload.
If you used console.log, it’s stripped in production builds. Switch to console.warn or console.error, redeploy, and re-trigger.
Narrow the time range, set a function filter, and prefix your logs with tags so you can grep. For high-traffic apps, consider sending structured logs to a dedicated observability tool instead.
You’re probably logging the error’s message string instead of the Error object. Do console.error(err), not console.error(err.message) — the first preserves the stack trace.
Very long build outputs may be clipped in the inline viewer. Click Download full log (if available) for the complete output, or reproduce the build locally with the same command shown at the top of the deployment.

​
What’s Next?

Use the Terminal

Debug interactively inside your container

Deployments Reference

Understand the build and release pipeline