---
title: Post Check (Deprecated)
description: Create a check-run on a pull request. Deprecated in favor of Merge Protections.
---

:::danger
  The `post_check` action is **deprecated** and will be removed in a future
  release. Use [Merge Protections](/merge-protections) instead.

  Mergify will automatically migrate your configuration by removing
  `post_check` rules and opening a migration pull request that converts them
  to equivalent merge protections.
:::

## Migrating to Merge Protections

[Merge Protections](/merge-protections) replace `post_check` by letting you
define `success_conditions` directly, without creating an intermediate
check-run.

### Before (post_check)

```yaml
pull_request_rules:
  - name: Check CI status
    conditions:
      - base=main
    actions:
      post_check:
        success_conditions:
          - check-success=ci/test
        neutral_conditions:
          - check-neutral=ci/lint
        title: "Mergify check: {{ check_rule_name }}"
        summary: |
          {{ check_conditions }}
```

### After (Merge Protections)

```yaml
merge_protections:
  - name: Check CI status
    if:
      - base=main
    success_conditions:
      - or:
          - check-success=ci/test
          - check-neutral=ci/lint
```

:::note
  The `title` and `summary` options have no equivalent in Merge Protections
  and will be dropped during the automatic migration.
:::

:::note
  When both `success_conditions` and `neutral_conditions` are defined, the
  migration wraps them in a single `or`, as above. When only one of the two is
  defined, its conditions are copied across as-is. When neither is defined, the
  `post_check` action is removed without a replacement merge protection.
:::

---

## Legacy Reference

The `post_check` action allows Mergify to create a check-run on a pull request.
This can be useful in situations where you want to add a custom check to the
status of a pull request based on Mergify's evaluation.

<Image
  src={PostCheckScreenshot}
  alt="A post_check check-run in a GitHub pull request's checks list, flagging a title that breaks Conventional Commit"
/>

### Parameters

| Key name | Value type | Default | Description |
| --- | --- | --- | --- |
| `neutral_conditions` | List of conditions or null | `null` | List of conditions to match to mark the pull request check as neutral, otherwise, it will be marked as failing. |
| `success_conditions` | List of conditions or null | `null` | List of conditions to match to mark the pull request check as succeeded, otherwise, it will be marked as failing. If unset, the conditions from the rule that triggers this action are used. |
| `summary` | template | `"{{ check_conditions }}"` | The summary of the check. |
| `title` | template | `"'{{ check_rule_name }}'{% if check_status == 'success' %} succeeded{% elif check_status == 'failure' %} failed{% endif %}"` | The title of the check. |

As the `title` and `summary` are
[templates](/configuration/data-types#legacy-template), you can benefit from any [pull
request attributes](/configuration/conditions#attributes-list), e.g. `{{author}}`,
and also these additional variables:

- `{{ check_rule_name }}` the name of the rule that triggered this action;

- `{{ check_status }}` the resulting check-run status: `success` when the
  `success_conditions` match, `neutral` when the `neutral_conditions` match,
  and `failure` otherwise. When neither option is set, the triggering rule's
  own conditions decide between `success` and `failure`;

- `{{ check_succeeded }}` is `true` if `check_status` is `success`, `false`
  otherwise;

- `{{ check_conditions }}` the `success_conditions` with a checkbox marked
  against each one that matches. It is empty when only `neutral_conditions` is
  set, and falls back to the triggering rule's own conditions when neither
  option is set.

`{{ check_succeed }}` is also available as an alias of `{{ check_succeeded }}`,
kept for backward compatibility.