Find Your Application Logs

This page shows you where to view, search and tail your application's logs, how
those logs are collected, and what to check when the logs you expect are missing.

There are three places to read application logs, depending on what you have:

How logs are collected

The platform collects whatever your containers write to standard output
(stdout) and standard error (stderr). Nothing else is picked up: if your
application writes its logs to a file inside the container, those lines never
leave the pod and do not appear in SVIEW or Grafana.

To make sure your logs are collected:

• Log to stdout/stderr. For frameworks that default to a log file, switch the
  file appender or handler to the console.
• Prefer one JSON object per line. Plain text works, but structured JSON lets
  you filter on individual fields in Grafana (for example | json | level="error")
  instead of matching raw text.
• Keep one event per line. A multi-line stack trace printed as separate lines
  becomes separate log entries; a JSON logger that puts the trace in one field
  keeps it together.
• Never log secrets, tokens or personal data. Anyone who can read the logs can
  read them.

View logs in SVIEW

1. In SVIEW, open Applications → Deployments in the sidebar.
2. Select the deployment for your application and environment.
3. Open the Logs tab.
4. Choose a mode:
   • Live Stream shows new lines as they arrive. Leave Follow selected to
     keep scrolling to the newest line, and use Clear to empty the view.
   • Search looks back in time. Click a preset — Last 15m, Last 1h,
     Last 2h or Last 6h — or set From and To and click Search.
5. Optionally type into Filter logs… to show only lines containing that
   text. Matches are highlighted.

If the stream is running but nothing has been written yet, the view shows
Waiting for logs…. A search with no results shows No log lines found.

View logs in Grafana

If your team has a dedicated observability stack, the same logs are in Loki and
can be searched beyond the SVIEW window. In Grafana, go to Explore, select
the Loki data source, and filter by namespace:

{namespace="your-namespace"} |= "error"

With JSON logs, parse the fields and filter on them:

{namespace="your-namespace"} | json | level="error"

Getting Grafana access and requesting a stack are covered in
Observability.

View logs with kubectl

With temporary namespace access (see Namespace Access),
you can read a pod's output directly:

kubectl logs -f <pod-name> -n <namespace>          # tail live output
kubectl logs <pod-name> -n <namespace> --previous  # the run before the last restart

kubectl logs only sees pods that exist now, and only the current and the
previous run of each container. Use SVIEW or Grafana for anything older.

Why logs might be missing

Check these in order:

1. The application writes to a file, not stdout. Only stdout/stderr is
   collected. Change the logging configuration and redeploy.
2. The wrong deployment or environment is selected. Each environment has its
   own deployment in SVIEW; production logs are not shown on the staging one.
   If your application is split into several deployments, open the one that
   actually runs the code you are looking for.
3. The time range is too narrow or too old. Widen the search within the
   6-hour limit, or use Grafana for older periods.
4. The pod restarted or was replaced. kubectl logs loses the history of a
   replaced pod; SVIEW and Grafana still have it for the period they keep.
5. There is no Logs tab at all. The tab is hidden when logs are not
   available for that deployment — for example when it is a platform component
   rather than your application, or when SVIEW cannot currently reach the
   cluster. It is also hidden if your SVIEW account does not include log access.
   Raise a request in your dedicated Slack channel with the deployment name, and
   say whether colleagues can see the tab.

How long logs are kept

Retention depends on how logging is set up for your environments, and differs
between the SVIEW view, a dedicated observability stack and any cloud logging
you run yourself. If you need logs kept for a specific period — for an audit,
a compliance requirement or incident investigations — raise a request in your
dedicated Slack channel stating the period you need, and CTO2B will confirm what
is in place today and what changing it would involve.

Sending logs to an external tool

If you want your logs in an external log management tool as well, raise a request
in your dedicated Slack channel naming the tool, the environments and
namespaces to include, and how the tool receives logs (for example an endpoint
and API key held in your secrets). CTO2B will confirm whether and how it can be
set up for your environments.

Related articles

• Observability — what you get by default, and requesting a dedicated Grafana, Prometheus and Loki stack
• Namespace Access — temporary kubectl access to your namespaces
• Pod Keeps Restarting (CrashLoopBackOff) — reading logs of an application that will not start
• Restart an Application or a Single Pod
• Audit Logs — who did what in SVIEW, not application output