---
title: "Understanding Service Logs"
slug: "understanding-service-logs"
tags: ["troubleshooting"]
updated: 2026-07-16T19:33:19Z
published: 2026-07-16T19:33:19Z
canonical: "docs.unqork.io/understanding-service-logs"
---

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

# Understanding Service Logs

Service logs in Unqork let Creators and Administrators review API service call information. This article covers how to read service logs and how to use the service logs API call. The service logs collect all API calls made in Unqork, including calls to internal and external services.

In [Services Administration](/docs/services-administration), define which services connect to the application. Choose to log the request and response bodies for API calls. This information is useful when troubleshooting failed calls. When a call fails, service logs can show exactly why.

## Setting up Service Logs for External APIs

Use [Services Administration](/docs/services-administration) to set up which APIs to log. Capturing request and response bodies provides the right information to troubleshoot any failed call.

Set up logging preferences in the Logging section of Services Administration.

| Setting | Description |
| --- | --- |
| Capture request and response bodies | When set to **ON**, this setting enables logging for this service. |
| Retention days | Enter the number of days to retain service logs. This setting only applies to external API calls. For internal services, service logs are retained for 30 days in Production environments and three days in other environments. |
| PagerDuty service key | Enter a service key to connect service logs with PagerDuty for alerting. See [PagerDuty API key documentation](https://support.pagerduty.com/main/docs/pagerduty-agent-integration-guide#send-an-event-to-pagerduty) for setup details. |

Once logging settings are configured, service logs automatically save to Unqork's database so they can be queried at any time.

## Setting up Service Logs for Remote Executes

Set up service logs to capture the details of remote execute calls. Remote executes run a module on Unqork's server instead of in the end-user's browser. Capturing the request and response bodies of calls makes future troubleshooting easier. Set up the request and response body log through [Environment Administration](/docs/environment-administration).

The following options are available in the **Server Side Execution Request/Response Body Log** drop-down in **Environment Administration**.

### Server Side Execution Request/Response Body Log Settings

| Setting | Description |
| --- | --- |
| Do not capture request/response bodies | Logs will not show the details of remote execute calls. |
| Capture request/response bodies on failure | Unqork only logs request and response bodies if a remote execute fails. |
| Capture all request/response bodies | Unqork logs request and response bodies for all remote executes. |

Select **Capture all request/response bodies**. Even successful calls can return incorrect data, and logging both sides provides everything needed to troubleshoot any issue.

> Set up PagerDuty alerts from Environment Administration. When configured, PagerDuty sends alerts when there are errors in the Unqork application. To use the PagerDuty integration, a PagerDuty account is required. Visit [PagerDuty](https://www.pagerduty.com/) to set up an account.

## Checking Service Logs Using an API Call

To retrieve service logs, enter the following endpoint in the browser:

`https://{your-environment}.unqork.io/fbu/uapi/logs/services`

Replace `{your-environment}` with the name of the Unqork environment.

> Install a Chrome extension that formats JSON. Without one, service logs return as long lines of unformatted text.

The table below describes each response item in the service logs.

| Response Item | Description |
| --- | --- |
| `id` | A unique identifier for the service log. |
| `type` | The most common values are `service` (any external API set up in Services Administration) and `remoteExecute` (any module that runs on the server). |
| `submissionId` | A basic identifier for each submission made. End-users create a new submission any time they save or submit a module. |
| `requestTime` | The date and time when the request was made to the remote execute or external service. Filter searches to a specific time using `requestTime` and `responseTime`. |
| `responseTime` | The date and time when the module finished running and sent a response, or when the external API finished and sent a response. Filter searches to a specific time using `requestTime` and `responseTime`. |
| `duration` | The total time the service execution took, measured from start to completion. |
| `serviceName` | The name of the service added in Services Administration. |
| `userId` | The user ID of the Creator or integration job that submitted the request. Filtering by user ID can help identify what went wrong for a specific end-user. |
| `url` | The URL of the request made. |
| `method` | The type of operation or request performed (for example, GET, POST, or PUT), which indicates how the service was called. |
| `responseText` | Text with a basic description of the `responseCode`. Some examples include `Bad Request`, `Not Found`, or `OK`. |
| `responseCode` | HTTP response status codes. Common ranges: **100–199** (Informational), **200–299** (Successful), **300–399** (Redirection), **400–499** (Client error), **500–599** (Server error). |
| `requestBody` | The details of the API call or the remote execute request. A `requestBody` is only available for POST and PUT calls. |
| `responseBody` | The details returned from the call. Depending on the API call, a `responseBody` is not always returned. |
| `eventLogCaptured` | A true or false value that indicates whether detailed event logs were collected during the service run. |
| `rootServiceLogId` | The identifier of the first service log in a chain of related service calls. Use this to trace back to the original call. |
| `parentServiceLogId` | The identifier of the parent service log, which links the current log to the service call that triggered it. |
| `expireAt` | The date and time when the record will drop off the log. The default is 30 days. Change this in Services Administration by updating the Retention days setting. |
| `created` | The date and time when Unqork created the log record. |
| `modified` | The date and time of a log's last modification. |
| `moduleId` | The ID of the executed module. In the case of a remote execute, the ID refers to the executed module. If logging a service, this ID indicates the module that made the API call. |

### Bringing Service Logs Directly into a Module

Bring service logs into a module using a [Plug-In component](/docs/plug-in-component):

1. From the **Internal Services** drop-down, select **Get Service Logs**.
2. Click **Save**.

## Searching and Filtering Service Logs

Because service logs store all API calls made in Unqork, finding a specific one can be difficult. Built-in filtering operators let you customize the search. Filter to failed calls only, calls made during a certain time frame, or remote executes only. The query string can specify the service name, filter conditions, and sorting.

For example, to return service logs for a specific service, enter the following API call in the browser: `https://{your-environment}.unqork.io/fbu/uapi/logs/services?serviceName={serviceName}`. Replace `{your-environment}` with the name of the Unqork environment. The response contains logs for the queried service.

For filtering options, see the [Filtering operators table on GitHub](https://github.com/loris/api-query-params).

---

**Changelog**

| Date | Change |
| --- | --- |
| 2026-07-16 | Initial publication. |

A reusable configuration in Unqork that defines how a module connects to an external system, including authentication method, host, and headers. Services are managed in Services Administration.

Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform.

APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services.

APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services.

In Unqork, an External API (application programming interfaces) connects to services outside of the Unqork platform. APIs are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services.

JSON (JavaScript Object Notation) is an open standard file and data interchange format. Unqork uses JSON for submission (record) data.

A URL (uniform resource locator) is a unique identifier used to locate a resource on the internet. Also known as a web address.

The HTTP POST method is used to send data to a server to create or update a resource, typically including the data in the body of the request.

HTTP (Hypertext Transfer Protocol) is an application-layer protocol used to transmit hypermedia documents like HTML.

DOM (Document Object Model) events are signals or notifications that something has occurred or is occurring within a web page, often triggered by user interactions or by the browser itself. These events allow JavaScript to react to changes and interactions on a web page, making it dynamic and interactive.