> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.

# View Deployment & Runtime Logs

> Debug production issues with CloudWatch-backed log streaming

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

| Log type            | What it shows                                           | Where to find it                   |
| ------------------- | ------------------------------------------------------- | ---------------------------------- |
| **Deployment logs** | Build steps, install output, release events             | Settings > Deployment History      |
| **Runtime logs**    | `console.log`, errors, request traces from your Lambdas | Hosting page, Runtime Logs section |

## Runtime Logs

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

<Steps>
  <Step title="Open the Hosting page">
    In your project, click **Hosting** in the sidebar.
  </Step>

  <Step title="Scroll to Runtime Logs">
    The Runtime Logs section is near the bottom of the page.
  </Step>

  <Step title="Pick an environment">
    Choose production, staging, or development — each environment has its own log stream.
  </Step>

  <Step title="Set a time range">
    Pick one of the presets or a custom range:

    * Last 60 minutes
    * Last 6 hours
    * Last 24 hours
    * Custom range
  </Step>

  <Step title="Set a limit">
    100, 500, or 1000 most recent entries. Higher limits take longer to load.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Info>
  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.
</Info>

## Deployment Logs

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

<Steps>
  <Step title="Open Deployment History">
    Go to **Settings > Deployment History**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Search within logs">
    Use Cmd+F (Ctrl+F on Windows) to search the expanded log for error messages or specific output.
  </Step>
</Steps>

## What Gets Logged

| Call                 | Visible in production?                 |
| -------------------- | -------------------------------------- |
| `console.log(...)`   | **No** — stripped in production builds |
| `console.info(...)`  | No                                     |
| `console.warn(...)`  | Yes                                    |
| `console.error(...)` | Yes                                    |
| Thrown errors        | Yes, with stack traces                 |

<Warning>
  `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`.
</Warning>

## Useful Patterns

### Tag logs for filtering

Prefix messages so you can search by area of your app:

```typescript theme={null}
console.warn('[payment]', { action: 'create-checkout', amount, userId });
console.error('[payment] checkout failed', { error: err.message, userId });
```

Then filter by `[payment]` in the log viewer.

### Log errors as Error objects, not strings

```typescript theme={null}
// Good — Hiveku captures the full stack trace
console.error('DB query failed', err);

// Less useful — no stack trace
console.error(`DB query failed: ${err.message}`);
```

### Include structured context

```typescript theme={null}
console.warn('slow query', {
  duration_ms: duration,
  query: sql.slice(0, 200),
  user_id: userId,
});
```

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

## Verify Logs Are Flowing

<Steps>
  <Step title="Add a log line">
    In a Lambda function (API route or server action), add:

    ```typescript theme={null}
    console.error('[test-log]', 'hello from lambda', new Date().toISOString());
    ```
  </Step>

  <Step title="Deploy">
    Push the change through your normal deploy flow.
  </Step>

  <Step title="Trigger the function">
    Call the API route or navigate to the page that runs it.
  </Step>

  <Step title="Check Runtime Logs">
    Open the Hosting page and scroll to Runtime Logs. Your `[test-log]` message should appear within a minute.
  </Step>
</Steps>

See the [deployments reference](/publishing/deployments) for more on how builds and releases work.

## Troubleshooting

<AccordionGroup>
  <Accordion title="No logs showing at all">
    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.
  </Accordion>

  <Accordion title="My log message is missing">
    If you used `console.log`, it's stripped in production builds. Switch to `console.warn` or `console.error`, redeploy, and re-trigger.
  </Accordion>

  <Accordion title="Too many log lines — can't find anything">
    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.
  </Accordion>

  <Accordion title="Error logs show 'Error' with no stack trace">
    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.
  </Accordion>

  <Accordion title="Deployment log is truncated">
    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.
  </Accordion>
</AccordionGroup>

## What's Next?

<CardGroup cols={2}>
  <Card title="Use the Terminal" icon="terminal" href="/how-tos/use-terminal">
    Debug interactively inside your container
  </Card>

  <Card title="Deployments Reference" icon="rocket" href="/publishing/deployments">
    Understand the build and release pipeline
  </Card>
</CardGroup>