---
title: "Logs for a batch job"
method: GET
path: "/jobs/{job_id}/logs"
tags: ["Data Processing", "Batch Jobs"]
---

# Logs for a batch job

`GET /jobs/{job_id}/logs`

Lists log entries for the batch job, usually for debugging purposes.

Back-ends can log any information that may be relevant for a user
at any stage (status) of the batch job.
Users can log information during data processing using respective
processes such as `inspect`.

If requested consecutively, it is RECOMMENDED that clients use the offset
parameter to get only the entries they have not received yet.

While pagination itself is OPTIONAL, the `offset` parameter is REQUIRED
to be implemented by back-ends.

## Path parameters

- `job_id` string, required — Per-back-end unique identifier of the batch job, generated by the back-end during creation. MUST match the specified pattern.

## Query parameters

- `offset` string
- `level` 'error' | 'warning' | 'info' | 'debug'
- `limit` integer

## Response `200`

Lists the requested log entries.

- object
  - `level` 'error' | 'warning' | 'info' | 'debug' — The minimum severity level for log entries that the back-end returns. This property MUST reflect the effective lowest `level` that may appear in the document, which is (if implemented) the highest level of: 1. the `log_level` specified by the user for the processing request. 2. the `level` specified by the user for the log request. The order of the levels is as follows (from low to high severity): `debug`, `info`, `warning`, `error`. That means if `warning` is set, the logs will only contain entries with the level `warning` and `error`.
  - `logs` LogEntry[], required — A chronological list of logs.
    - `id` string, required — An unique identifier for the log message, could simply be an incrementing number.
    - `code` string — The code is either one of the standardized error codes or a custom code, for example specified by a user in the `inspect` process.
    - `level` 'error' | 'warning' | 'info' | 'debug', required — The severity level of the log entry. The order of the levels is as follows (from low to high severity): `debug`, `info`, `warning`, `error`. The level `error` usually corresponds with critical issues that usually terminate the data processing.
    - `message` string, required — A concise message explaining the log entry. Messages do *not* explicitly support [CommonMark 0.29](http://commonmark.org/) syntax as other descriptive fields in the openEO API do, but the messages MAY contain line breaks or indentation. It is NOT RECOMMENDED to add stacktraces to the `message`.
    - `time` string, date-time — The date and time the event happened, in UTC. Formatted as a [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339.html) date-time.
    - `data` unknown
    - `path` object[] — Describes where the log entry originates from. The first element of the array is the process that has triggered the log entry, the second element is the parent of the process that has triggered the log entry, etc. This pattern is followed until the root of the process graph.
      - `node_id` string, required — The id of the node the log entry originates from.
      - `process_id` string — The identifier for the process. It MUST be unique across its namespace (e.g. predefined processes or user-defined processes). Clients SHOULD warn the user if a user-defined process is added with the same identifier as one of the predefined process.
      - `namespace` string, nullable — The namespace the `process_id` is valid for. The following options are predefined by the openEO API, but additional namespaces may be introduced by back-ends or in a future version of the API. * `null` (default): Checks both user-defined and predefined processes, but prefers user-defined processes if both are available. This allows users to add missing predefined processes for portability, e.g. common processes from [processes.openeo.org](https://processes.openeo.org) that have a process graph included. Logging the namespace selected by the back-end for debugging purposes is RECOMMENDED. * `backend`: Uses exclusively the predefined processes listed at `GET /processes`. * `user`: Uses exclusively the user-defined processes listed at `GET /process_graphs`. If multiple processes with the same identifier exist, Clients SHOULD inform the user that it's recommended to select a namespace.
      - `parameter` string, nullable — If applicable, the name of the parameter the log entry corresponds to.
    - `usage` Usage
      - `cpu` UsageMetric
        - `value` number, required
        - `unit` string, required
      - `memory` UsageMetric
        - `value` number, required
        - `unit` string, required
      - `duration` UsageMetric
        - `value` number, required
        - `unit` string, required
      - `network` UsageMetric
        - `value` number, required
        - `unit` string, required
      - `disk` UsageMetric
        - `value` number, required
        - `unit` string, required
      - `storage` UsageMetric
        - `value` number, required
        - `unit` string, required
    - `stacktrace` string — A stacktrace or similar, may include whitespaces for formatting.
    - `links` Link[] — Links related to this log entry / error, e.g. to a resource that provides further explanations. For relation types see the lists of [common relation types in openEO](#section/API-Principles/Web-Linking).
      - `rel` string, required — Relationship between the current document and the linked document. SHOULD be a [registered link relation type](https://www.iana.org/assignments/link-relations/link-relations.xml) whenever feasible.
      - `href` string, uri, required — The value MUST be a valid URL.
      - `type` string — The value MUST be a string that hints at the format used to represent data at the provided URI, preferably a media (MIME) type.
      - `title` string — Used as a human-readable label for a link.
  - `links` Link[], required — Links related to this list of resources, for example links for pagination or alternative formats such as a human-readable HTML version. The links array MUST NOT be paginated. If pagination is implemented, the following `rel` (relation) types apply: 1. `next` (REQUIRED): A link to the next page, except on the last page. 2. `prev` (OPTIONAL): A link to the previous page, except on the first page. 3. `first` (OPTIONAL): A link to the first page, except on the first page. 4. `last` (OPTIONAL): A link to the last page, except on the last page. For additional relation types see also the lists of [common relation types in openEO](#section/API-Principles/Web-Linking).
    - `rel` string, required — Relationship between the current document and the linked document. SHOULD be a [registered link relation type](https://www.iana.org/assignments/link-relations/link-relations.xml) whenever feasible.
    - `href` string, uri, required — The value MUST be a valid URL.
    - `type` string — The value MUST be a string that hints at the format used to represent data at the provided URI, preferably a media (MIME) type.
    - `title` string — Used as a human-readable label for a link.

## Other responses

- `4XX` — The request can not be fulfilled due to an error on client-side, i.e. the request is invalid. The client SHOULD NOT repeat the request without modifications. The response body SHOULD contain a JSON error object. MUST be any HTTP status code specified in [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231.html#section-6.6). This request MUST respond with HTTP status codes 401 if authorization is required or 403 if the authorization failed or access is forbidden in general to the authenticated user. HTTP status code 404 SHOULD be used if the value of a path parameter is invalid. See also: * [Error Handling](#section/API-Principles/Error-Handling) in the API in general. * [Common Error Codes](errors.json)
- `5XX` — The request can not be fulfilled due to an error at the back-end. The error is never the client’s fault and therefore it is reasonable for the client to retry the exact same request that triggered this response. The response body SHOULD contain a JSON error object. MUST be any HTTP status code specified in [RFC 7231](https://www.rfc-editor.org/rfc/rfc7231.html#section-6.6). See also: * [Error Handling](#section/API-Principles/Error-Handling) in the API in general. * [Common Error Codes](errors.json)

---

[API](https://skmtc.net/open-eo/apis/openeo-api.md) · [All operations](https://skmtc.net/open-eo/apis/openeo-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/open-eo/openeo-api/versions/0c5e31955a19/schema)