> ## Documentation Index > Fetch the complete documentation index at: https://docs-platform.crewai.com/llms.txt > Use this file to discover all available pages before exploring further. # Kickoff Crew > Kickoff a Crew on CrewAI AMP ## Overview Once you've deployed your crew to the CrewAI AMP platform, you can kickoff executions through the web interface or the API. This guide covers both approaches. ## Method 1: Using the Web Interface ### Step 1: Navigate to Your Deployed Crew 1. Log in to [CrewAI AMP](https://app.crewai.com) 2. Click on the crew name from your projects list 3. You'll be taken to the crew's detail page Crew Dashboard ### Step 2: Initiate Execution From your crew's detail page, you have two options to kickoff an execution: #### Option A: Quick Kickoff 1. Click the `Kickoff` link in the Test Endpoints section 2. Enter the required input parameters for your crew in the JSON editor 3. Click the `Send Request` button Kickoff Endpoint #### Option B: Using the Visual Interface 1. Click the `Run` tab in the crew detail page 2. Enter the required inputs in the form fields 3. Click the `Run Crew` button Run Crew ### Step 3: Monitor Execution Progress After initiating the execution: 1. You'll receive a response containing a `kickoff_id` - **copy this ID** 2. This ID is essential for tracking your execution Copy Task ID ### Step 4: Check Execution Status To monitor the progress of your execution: 1. Click the "Status" endpoint in the Test Endpoints section 2. Paste the `kickoff_id` into the designated field 3. Click the "Get Status" button Get Status The status response will show: * Current execution state (`running`, `completed`, etc.) * Details about which tasks are in progress * Any outputs produced so far ### Step 5: View Final Results Once execution is complete: 1. The status will change to `completed` 2. You can view the full execution results and outputs 3. For a more detailed view, check the `Executions` tab in the crew detail page ## Method 2: Using the API You can also kickoff crews programmatically using the CrewAI AMP REST API. ### Authentication All API requests require a bearer token for authentication: ```bash theme={null} curl -H "Authorization: Bearer YOUR_CREW_TOKEN" https://your-crew-url.crewai.com ``` Your bearer token is available on the Status tab of your crew's detail page. ### Checking Crew Health Before executing operations, you can verify that your crew is running properly: ```bash theme={null} curl -H "Authorization: Bearer YOUR_CREW_TOKEN" https://your-crew-url.crewai.com ``` A successful response will return a message indicating the crew is operational: ``` Healthy% ``` ### Step 1: Retrieve Required Inputs First, determine what inputs your crew requires: ```bash theme={null} curl -X GET \ -H "Authorization: Bearer YOUR_CREW_TOKEN" \ https://your-crew-url.crewai.com/inputs ``` The response will be a JSON object containing an array of required input parameters, for example: ```json theme={null} { "inputs": ["topic", "current_year"] } ``` This example shows that this particular crew requires two inputs: `topic` and `current_year`. ### Step 2: Kickoff Execution Initiate execution by providing the required inputs: ```bash theme={null} curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_CREW_TOKEN" \ -d '{"inputs": {"topic": "AI Agent Frameworks", "current_year": "2025"}}' \ https://your-crew-url.crewai.com/kickoff ``` The response will include a `kickoff_id` that you'll need for tracking: ```json theme={null} { "kickoff_id": "abcd1234-5678-90ef-ghij-klmnopqrstuv" } ``` ### Step 3: Check Execution Status Use the `kickoff_id` to get the status of the execution: ```bash theme={null} curl -X GET \ -H "Authorization: Bearer YOUR_CREW_TOKEN" \ https://your-crew-url.crewai.com/status/abcd1234-5678-90ef-ghij-klmnopqrstuv ``` The response shows the state of the execution, the progress, and the result. Send the request again to get a new response. This is an example response for a crew that runs: ```json theme={null} { "state": "RUNNING", "status": "Task is Running", "progress": { "unit": "task", "completed": 1, "total": 3, "remaining": 2, "current": "write_report", "current_agent": "Researcher", "started_at": "2025-09-10T18:00:00+00:00", "updated_at": "2025-09-10T18:02:14+00:00", "duration_seconds": 134.0 }, "last_event": { "type": "tool_usage_started", "timestamp": "2025-09-10T18:02:14+00:00", "tool_name": "SerperDevTool", "agent_role": "Researcher" }, "events_count": 24, "events_by_type": { "crew_kickoff_started": 1, "task_started": 2, "agent_execution_started": 2, "tool_usage_started": 3 }, "triggered_by": { "type": "user", "id": "4711" }, "execution_origin": "api", "source": "memory" } ``` #### Response Fields | Field | Description | | - | - | | `state` | The state of the execution: `PENDING`, `STARTED`, `RUNNING`, `SUCCESS`, `FAILED`, `PAUSED` or `REVOKED`. | | `status` | A short message about the state. | | `result` | The final output. The field is empty until the execution stops. | | `result_json` | The final output as JSON, if the output is a JSON object. | | `usage_metrics` | The token counts for the execution. | | `progress` | How much of the work is complete. Refer to [Progress](#progress). | | `last_event` | The most recent event. Refer to [Events](#events). | | `events` | The most recent events. The oldest event is first. | | `events_count` | The number of events that the execution sent. | | `events_by_type` | The number of events of each type. | | `triggered_by` | The identity that started the execution. Refer to [Attribution](#attribution). | | `execution_origin` | The source of the request. Refer to [Execution Origin](#execution-origin). | | `last_step` | The most recent agent step. Crews only. | | `last_executed_task` | The most recent task that the crew completed. Crews only. | | `flow_id` | The identifier of a flow that waits for human feedback. | | `source` | The source of the data: `memory` or `application`. | A field that has no value is `null`. #### Progress The `progress` object shows how much of the work is complete. | Field | Description | | - | - | | `unit` | The unit of work. A crew uses `task`. A flow uses `step`. | | `completed` | The number of units that are complete. | | `total` | The number of units in the execution. | | `remaining` | The number of units that are not complete. | | `current` | The name of the task or the method that runs now. | | `current_agent` | The role of the agent that works now. | | `started_at` | The time when the worker started the execution. | | `updated_at` | The time of the most recent change. | | `duration_seconds` | The number of seconds from the start to `updated_at`. | A flow selects the next step while it runs. The number of steps is not known before the flow stops. For a flow, `total` and `remaining` are always `null`: ```json theme={null} { "unit": "step", "completed": 4, "total": null, "remaining": null, "current": "summarize", "current_agent": null, "started_at": "2025-09-10T18:00:00+00:00", "updated_at": "2025-09-10T18:00:41+00:00", "duration_seconds": 41.2 } ``` Do not calculate a percentage for a flow. Show the value of `completed` as a count of the steps. #### Events An event shows what the execution did at a given time. Each event is a summary. An event does not contain the prompts, the outputs or the state of the flow. | Field | Description | | - | - | | `type` | The type of the event, for example `task_started`. | | `timestamp` | The time of the event. | | `crew_name` | The name of the crew, if the event has one. | | `flow_name` | The name of the flow, if the event has one. | | `method_name` | The name of the flow method, if the event has one. | | `task_name` | The name of the task, if the event has one. | | `agent_role` | The role of the agent, if the event has one. | | `tool_name` | The name of the tool, if the event has one. | | `model` | The name of the model, if the event has one. | | `error` | The error message, if the event has one. | The `events` list keeps the 100 most recent events. If the execution sends more events, the platform removes the oldest events from the list. The `events_count` field gives the number of all the events. The `events_by_type` field also counts all the events. These two fields stay correct when the list is full. #### Attribution The `triggered_by` object tells you who started the execution. | Field | Description | | - | - | | `type` | The type of the identity: `user`, `service_account` or `unknown`. | | `id` | The identifier of the identity in CrewAI AMP. | The response gives the type and the identifier only. It does not give the name, the email address or the organization. Each token for a deployment can read the status of each execution of that deployment. The response does not include personal data. If the request uses the static `AUTH_TOKEN` of the deployment, the type is `unknown`. If the platform does not know the identity, `triggered_by` is `null`. #### Execution Origin The `execution_origin` field tells you how the execution started. | Value | Description | | - | - | | `ui` | A user started the execution from the CrewAI AMP interface. | | `schedule` | A schedule started the execution. | | `trigger` | An automation trigger started the execution. | | `chat` | A chat message started the execution. | | `hitl-resume` | The platform continued the execution after human feedback. | | `replay` | A replay started the execution. | | `api` | A request to the API of the deployment started the execution. | #### Optional Settings Set these environment variables on the deployment to change the event log. | Variable | Default | Description | | - | - | - | | `CREWAI_STATUS_EVENTS` | `true` | Set the value to `false` to stop the event log and the progress data. | | `CREWAI_STATUS_MAX_EVENTS` | `100` | The number of events in the `events` list. | | `CREWAI_STATUS_EVENT_FLUSH_SECONDS` | `2.0` | The minimum number of seconds between two writes of the event log. | These limits apply: * A deployment that runs crewAI 1.15.21 or before gives `null` for the progress data and for the event data. Upgrade the crewAI version in your project, then deploy the crew again. * An execution that waits in the queue has the state `PENDING`. It gives `null` for `triggered_by`. * A flow that continues after human feedback counts only the steps after the feedback. * A response that has `"source": "application"` gives `null` for the progress data and for the event data. ## Handling Executions ### Long-Running Executions For executions that may take a long time: 1. Consider implementing a polling mechanism to check status periodically 2. Use webhooks (if available) for notification when execution completes 3. Implement error handling for potential timeouts ### Execution Context The execution context includes: * Inputs provided at kickoff * Environment variables configured during deployment * Any state maintained between tasks ### Debugging Failed Executions If an execution fails: 1. Check the "Executions" tab for detailed logs 2. Review the "Traces" tab for step-by-step execution details 3. Look for LLM responses and tool usage in the trace details Contact our support team for assistance with execution issues or questions about the Enterprise platform. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.