> For the complete documentation index, see [llms.txt](https://docs.aviator.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aviator.co/mergequeue/concepts/sticky-comments.md).

# Sticky Comments

Aviator provides sticky comments to show the PR status within GitHub. Check out the core comments that are generated to better understand when you can see them.

In addition to the dashboard, Aviator provides sticky comments to give you the status of a PR within GitHub.

By default, Aviator posts a comment when a PR is opened, and will automatically update the comment as the PR moves through its lifecycle. This is a great way to stay up to date and identify any reasons that may have dequeued your PR or is preventing your PR from merging. Use `merge_rules.status_comment.publish` to change when the comment is first posted, for example to hold it until the PR is queued. See [<mark style="color:blue;">Customize Sticky Comments</mark>](/mergequeue/how-to-guides/customize-sticky-comments.md).

<figure><img src="https://273246003-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOAPqUQVbLbsfI5YESl32%2Fuploads%2FYFVjUMCwHkZXvnb1cgHV%2FScreen%20Shot%202023-04-24%20at%2012.31.23%20PM.png?alt=media&amp;token=9163f124-132f-4582-a9be-e35eda3e32d6" alt=""><figcaption></figcaption></figure>

Having a sticky comment makes it easy for developers to find the status of the PR in one place, and also reduces noise if you set up notifications for new GitHub comments.

{% hint style="info" %}
You can also [<mark style="color:blue;">customize these sticky comments</mark>](/mergequeue/how-to-guides/customize-sticky-comments.md).
{% endhint %}

The following are some of the important of comments that are generated when comments are enabled:

* **CI is taking longer than expected.** - This is only applicable in Parallel mode. It can happen if the draft PR CI is completed but the original PR is still pending CI status. If the PR is `stuck`, then the comment will also provide info on when the PR will be dequeued and which CI(s) are stuck.
* **This PR is queued for merge (queue position: \<number>).** - Reports successful queuing along with the current position of the PR in the queue. Info on pending status checks will also be provided.
* **PR failed to merge with reason: \<reason>** - Reports a PR getting dequeued with one of the reasons as described above. It may also contained information about the associated draft PR if relevant along with additional debug info.
* **CI for this PR is waiting to be queued \<note>. CI for this PR will run automatically when the queue catches up.**
* **This PR was merged using MergeQueue.**
* **This PR was merged manually.**
* **This PR was closed without merging. If you still want to merge this PR, re-open it.**
* **This PR is not ready to merge (currently in state \<status>: \<description>).**

#### Stacked PRs

The following comments are only applicable if you are using Stacked PRs.

* **Waiting for the previous PR in this stack to be queued (or merged) before queuing this PR.** - This is only applicable if using stacked PRs.
* **This PR is stacked on top of \<PR#>. Changes from this PR can be reviewed separately and changes to the parent PR will automatically be synced into this PR.**
* **Next PR in this stack: \<dependent PR#s>**

#### ChangeSets

The following comments are only applicable if you are using ChangeSets.

* **PR has been added to the ChangeSet.**
* **MergeQueue ChangeSet actions: \[View Changeset dashboard]\<dashboard\_url>**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.aviator.co/mergequeue/concepts/sticky-comments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.