---
title: "状态与事件"
description: "部署状态取值与其对应事件时间线。"
---

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

# 状态与事件

## 简要定义

**状态**回答"现在能不能用"，**事件**回答"为什么变成这样"。排查时把它们放在一起读，才能区分输入错误、执行失败、健康检查失败和访问层未就绪这几种完全不同的情况。

## 为什么存在这个概念

只看当前状态无法判断"是刚开始变差还是已经稳定在这个状态很久了"。事件时间线提供了变化的因果链，配合当前状态一起看，才能判断应该继续等待、直接重试，还是需要回滚。

## 常见信号对照

| 你看到的信号 | 先检查 |
| --- | --- |
| 部署失败但旧版本仍可访问 | 新部署的事件、构建日志、健康检查 |
| 运行时健康但域名不可访问 | 代理状态、DNS、TLS 证书、路由规则 |
| 预览页面不存在 | Pull Request 状态、预览清理事件、部署产物 |
| 状态长时间停留在 pending | 运行中的任务、服务器连接、最近一次事件时间 |

> 如果状态和事件看起来互相矛盾，以事件时间线确认最后一次变化到底改变了什么，再决定是等待、重试还是回滚。

## 在 Web / CLI / API 中的体现

```bash
# 查看部署当前状态
appaloft deployments show <deploymentId>

# 跟随实时事件时间线
appaloft deployments timeline <deploymentId> --follow --json
```

## 排查顺序

1. **找到当前对象** — 先确认你在看的是项目、环境、资源、部署还是预览环境。不同对象的状态可能不同，不要把预览的失败当成生产环境失败。
2. **读取最后一次变化** — 查看最新事件的阶段、时间和错误码。如果最后事件只是"已接收请求"，说明任务可能仍在运行；如果最后事件已经是失败，进入恢复流程。
3. **对照健康摘要** — 事件解释历史，[健康摘要](/docs/troubleshoot/logs-health/)解释当前观察结果，两者要一起看。
4. **记录恢复证据** — 重试或回滚前记录失败状态、错误码、相关日志和访问地址，恢复后用同一组信息确认状态确实改变了。

## 常见误区

- **把 `pending` 当成卡死**：DNS 刚修改、部署刚提交时出现短暂的 `pending` 是正常的，先看最近事件时间再判断。
- **忽略预览环境和生产环境的区别**：预览环境的失败不代表生产环境有问题，反之亦然。

## 相关任务

- [查看日志与健康摘要](/docs/troubleshoot/logs-health/)
- [部署生命周期](/docs/deliver/lifecycle/)
- [常见故障与恢复](/docs/troubleshoot/recovery/)

Source: https://docs.appaloft.com/troubleshoot/status-events/index.mdx