# Operations

After the first deployment, the work shifts to spotting errors early, tracing releases, and going back to the last working state when needed.

> Source: https://www.application-platform.com/en/docs/operations/

In operation, the platform gives you three places to look: the Sentry project of your account for errors, the pipelines in GitLab for releases, and the **Servers** and **Domains** sections for the infrastructure. Monitored servers carry the **Monitored** badge, and their server card shows metrics such as utilization and network traffic; you switch monitoring on or off per server.

## Finding errors with Sentry

Error tracking runs through Sentry once you have connected your Sentry account under **Connections** and enabled the component under **Features**; otherwise it stays off. Errors from the app, the website, and the backend arrive there with a stack trace and the release version; you find the link on the Sentry tile in the project overview. [Error tracking]({{< relref "error-tracking" >}}) describes the connection, and [Working with Sentry]({{< relref "working-with-sentry" >}}) describes reading issues.

## Tracing releases

Every push to `main` produces a new version that the pipeline computes from the commit messages (`feat:` and `fix:` increment it). Which version runs on dev and production is recorded in the `gitops-configuration` repository; the builds and jobs are in GitLab under **CI/CD → Pipelines**. [Git workflow and deployment]({{< relref "git-workflow" >}}) describes the flow.

## Servers, domains, and logs

The connected servers of your organization are listed under **Servers**; how to create them is described in [Servers]({{< relref "servers" >}}). Under **Domains**, the platform keeps checking the DNS records and shows the result as a check mark in the **Status** column. The logs live on the server inside the Docker containers; [support]({{< relref "/support" >}}) helps you get access.

## When a release causes problems

1. Check in Sentry whether new errors have appeared since the release.
2. Check in GitLab under **CI/CD → Pipelines** whether the deployment completed.
3. In the pipeline of the last working `main` state, start the production job again with the play button; the previous version is live again.
4. If you get stuck, contact [support]({{< relref "/support" >}}).