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

# No on-call user was found

> The incident was created without an owner — and the organization owners got the notice.

When aciona.me cannot resolve an on-call person, it **still creates the incident** and notifies the organization owners. An alert is never dropped because of missing configuration.

This shows up on the timeline as a fallback event.

## Walk the chain

The responder is resolved through four links. One broken link is enough to leave the incident ownerless.

<Steps>
  <Step title="Does the alert have a service?">
    If the alert carried no service hint and the source has no default service, the chain stops here.

    **Fix:** set a default service on the source, or make the tool send the hint (`service` field, `service` label, `service:` tag).
  </Step>

  <Step title="Does the service have a responsible team?">
    **Auto-registered** services start with no team. This is the most common cause of this problem.

    **Fix:** under **Services**, link the service to the right team.
  </Step>

  <Step title="Does the team have an active schedule?">
    A team with no schedule, or with the schedule marked inactive, resolves nobody.

    **Fix:** create or re-activate the schedule under **Schedules**.
  </Step>

  <Step title="Does the schedule have a valid participant right now?">
    A schedule can exist and still point at nobody: no participants, participants who left the organization, or a rotation start in the future.

    **Fix:** review the participants and the rotation start date.
  </Step>
</Steps>

## Less obvious causes

<AccordionGroup>
  <Accordion title="The participant was deactivated" icon="user-minus">
    Deactivating a member does not remove them from schedules. The schedule still exists but points at someone who is no longer an active member.
  </Accordion>

  <Accordion title="Override with the wrong window" icon="calendar-x">
    An override entered in the wrong timezone can cover a different period than intended — leaving the real window uncovered.
  </Accordion>

  <Accordion title="Rotation start in the future" icon="clock">
    If the rotation start is later than the alert time, the schedule is not in effect yet.
  </Accordion>

  <Accordion title="The service recently changed teams" icon="git-branch">
    The new team may not have a schedule configured.
  </Accordion>
</AccordionGroup>

## How to prevent it

* Periodically review **services with no responsible team**.
* Keep at least **two participants** per schedule — so there is somewhere to escalate.
* When deactivating a member, check the schedules they belong to.
* Use [Who is on call](/en/on-call/who-is-on-call) to confirm coverage before relying on it.