Skip to main content
Log Explorer lets you browse, filter, and inspect logs from every app and service in a project’s environment, in one place in the Console, right from your browser. This includes application, access, cron, deployment, and platform logs (see log kinds for details), plus slow queries for MariaDB and MySQL, collected automatically. HIPAA projects are excluded entirely. When you want a diagnosis instead of just visibility, such as the likely cause of an error and a suggested fix, you can send that same view to the log-analyzer agent without re-describing what you found. This Console view covers the last 24 hours across all apps and services. For activity logs or individual log files via CLI and SSH, see Access your logs. For retention beyond either, set up log forwarding.

​
Availability

Log Explorer is available on projects running on AWS or Google Cloud Platform (GCP). It isn’t available on Microsoft Azure and OVHcloud projects.

​
Access control

Only Contributors and above can see Log Explorer. By default, these are the same roles that can connect over SSH and read log files directly, so Log Explorer typically doesn’t grant access beyond what SSH already allows. If you’ve customized SSH access with the access app configuration property, that doesn’t change who can see Log Explorer, so the two can diverge.

​
Retention

Log Explorer retains the last 24 hours of logs. Logs older than 24 hours are never displayed, regardless of the time window you select. If you need longer retention, log forwarding is unaffected by Log Explorer and can be set up separately.

​
Using Log Explorer

  1. Navigate to the project and environment whose logs you want to view.
  2. Optional: On the Logs tab, select the filters to apply and the time range.
    • A chart above the log list shows volume over that range, stacked by severity, so you can spot spikes or shifts before narrowing further.
    • Choose a relative time range, such as the last hour or last 24 hours, or a custom range; you can’t go back further than 24 hours, since that’s the retention window.
    • Filter by kind, severity, service, or unit, plus less common dimensions like instance, host, command, container ID, and container image; only values present in your selected time range are offered.
  3. Optional: In the log list, click a line to view its details: pretty-printed JSON for structured logs, or the raw payload otherwise. From there, you can filter to only logs sharing an attribute with that line, such as the same host or container, without rebuilding the filter by hand.
  4. Optional: Click Analyze <N> logs, confirm the window and filters, then click Analyze logs to send them to the log-analyzer agent instead of re-entering them. If you haven’t added the agent yet, click Help with logs instead to set it up.
Filters and time range are stored in the URL, so sharing a link shows the recipient the same view, provided they also have Contributor access or above. Otherwise, the link won’t show them the logs.

​
Log kinds

Every log line shown in Log Explorer is tagged with one kind, so you can isolate the category you’re troubleshooting instead of scanning everything mixed together:

​
Structured logging

Log Explorer can only infer severity from logs it can parse. An unstructured log line has no reliable signal to extract severity from, so it’s shown as INFO regardless of what actually happened. To get accurate severity, write your application logs as a single-line JSON object with a level field:
Log Explorer reads level and sets the log’s severity accordingly, instead of defaulting to INFO. Writing logs this way also avoids the multi-line log problem: a stack trace or multi-line message stays inside the one JSON object instead of being split into separate log lines. How you produce JSON-formatted logs depends on your application and language (for example, Monolog for PHP).
Last modified on October 23, 2026