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

# Create tickets

> Assign work to engineers in Linear or GitHub Issues

<Badge color="orange" icon="clock">Variable</Badge>

Create a ticket and assign it to the right team. The engineer investigates, decides on the fix, and resolves it on their schedule.

<Note>
  Use this when humans need to make decisions, the fix requires context you don't have, or you want to delegate without prescribing the solution.
</Note>

## How it works

Tero creates a ticket in your issue tracker with the affected service, evidence, cost impact, and suggested next steps. Tero assigns the ticket using service ownership from your [Master Catalog](/master-catalog/services).

## Setup

Connect your issue tracker:

<CardGroup cols={2}>
  <Card title="Linear" icon="square-kanban">
    Connect Linear to create issues in the right team's backlog.
  </Card>

  <Card title="GitHub Issues" icon="github">
    Create issues in the repository that owns the service.
  </Card>
</CardGroup>

## Example

Tero identifies that `user-service` has debug mode enabled. It's been emitting DEBUG-level logs for 3 days, generating 10x normal volume.

You approve the policy and select "Create tickets." Tero creates a ticket in Linear:

```
Title: Debug mode left on in user-service

user-service has been emitting DEBUG logs for 3 days.
This is generating 10x normal log volume (~$2,400/day in excess costs).

Debug logging was likely enabled for troubleshooting and not disabled afterward.

Action needed:
- Verify debug mode should be off
- Update the log level configuration
- Consider adding alerts for prolonged debug mode

Identified by Tero: https://app.tero.dev/policies/abc123
```

Tero assigns the ticket to the user-service team from your Master Catalog. They investigate, change the configuration, and close the ticket.

## When to use

Create tickets works best when:

* The fix requires human judgment (is this intentional?)
* Multiple solutions exist and the team should choose
* You want the work tracked in your backlog
* The issue can wait for a normal engineering workflow