Skip to main content
Activities log changes to your project, including when you deploy your app, when you push code, and when a cron job is run. To automate your workflows, you can parse and react to the activity’s JSON object through activity scripts.

Activity schema

Every activity has a corresponding JSON object containing all information for that activity, including timestamps, configuration, and sometimes logs. In practice, you can ignore much of the JSON object’s content. The most commonly used values are documented in this reference. The response differs depending on the activity and doesn’t always include all fields.

Example response

The following is a shortened example of a response for an environment sync activity. You can also see complete examples of responses.

id

A unique id value to identify the activity itself.

*_at

created_at, started_at, updated_at, cancelled_at, completed_at, and expires_at are all timestamps in UTC. For when a given activity occurred, use completed_at. You can use these properties to calculate the duration of the activity. To calculate the timing for steps in the activity, see the timings property.

parameters

The parameters property includes detailed information about what triggered the activity, such as the user, the impacted environment, the git commits, or the cron commands. The response changes based on the activity.

project

The ID of the project in which the activity took place. Use this value to distinguish multiple projects sent the same URL. Different from project activities.

type

The type of the activity in one of the following categories:

project activity types

Activities that happened on a given project. The following table presents the possible activity types:

environment activity types

Activities that happened on an environment. The following table presents the possible activity types:

integration activity types

Activities that relate to an integration. The following table presents the possible activity types:

maintenance activity types

Activities that relate to a maintenance. The following table presents the possible types:

environments

An array listing the environments that were involved in the activity. It’s usually only a single value representing one environment.

state

The current state of the activity. Its value can be pending, in_progress, complete, cancelled, or scheduled.

completion_percent

What percentage of the activity is complete.

result

Whether or not the activity completed successfully. If it did, the value is success. Note that certain activities, such as deploy hooks, can be marked as successful activities even if some commands failed.

timings

The amount of time required by the activity. It can include the following properties:

log

A human-friendly record of what happened in the activity. The log shouldn’t be parsed for data as its structure isn’t guaranteed.

description

A short machine-readable description of the activity.

text

A short human-readable description of the activity.

payload

Contains settings and details related to the completed activity. Its content varies based on the activity type.

user payload

Contains information about the Upsun user that triggered the activity.

environment payload

Contains information about the environment associated with the activity, including its settings, state, and deployment. The following table presents the most notable properties of the environment: Different from environment activities.

project payload

Contains information about the project associated with the activity, including plan details, timezone, and region. The following table presents the most notable properties of the project: Different from project activities.

deployment payload

Contains information about the deployed environment, if one is associated with the activity. The following table presents the most notable properties of the deployment: The payload.deployment property includes the configuration extracted from the following sources:

Maximum activities and parallelism

Project activities are distributed across separate queues, which enables two simultaneous activities to occur in parallel across your environments. For a given environment, only one activity can run at a time. Those queues include the following types of activities: Production activities are prioritized across all queues. When an activity for the production environment is triggered, it’s placed at the top of the queue. This makes it unlikely that activities on preview environments block activities for the production environment for long, though there may be a temporary wait.

Examples

The response is often usually long, so the following examples are shortened using ellipses. Remember that the response differs depending on the activity and not all fields are always available. To test responses, set up a webhook.

Cron

When a cron job is triggered, the activity contains all the job’s information. The following example response was triggered by a setting where the cron is scheduled to run every five minutes (5 * * * *) with the command sleep 60 && echo sleep-60-finished && date and times out after 86,400 seconds. To get details about the configured cron job, see the parameters property:
The following example shows the full activity response to a cron job:

Push

A push activity contains several properties. The commits property contains everything related to the Git push that triggered the activity:
The environment property contains the settings for the environment that was pushed to:
The deployment property contains the settings for the deployment, including the image type and resource allocation. The following example shows a shortened excerpt of the deployment property:
The following example shows the full activity response to a Git push:
Last modified on April 29, 2026