GAE中cron.yaml配置仅工作日任务及Run Now异常排查

我刚好也在做类似的GAE + Pub/Sub + .NET Web API调度服务，给你分享下解决这两个问题的经验：

1. 配置仅工作日触发的每日任务 #

GAE的cron.yaml支持标准CRON表达式，要实现仅工作日（周一到周五）触发，只需要把schedule字段的星期部分设为1-5（CRON规则里1代表周一，5代表周五）。

举个完整的配置示例：

cron:
- description: "工作日每日00:10执行任务"
  url: /your-pubsub-trigger-endpoint
  schedule: 10 0 * * 1-5
  timezone: "Asia/Shanghai" # 可选，指定时区避免UTC时差混淆
  target: your-service-version # 多版本服务时，指定目标运行版本

注意：如果不指定timezone，默认使用UTC时间，记得把你的本地00:10转换为UTC时间再配置（比如上海时区00:10对应UTC的16:10，schedule就要写成10 16 * * 1-5），所以直接指定时区会更直观。

2. 手动点击"Run Now"提示成功但任务未执行 #

这个问题我之前也踩过坑，大概率是这几个原因，你可以按顺序排查：

• 检查API的请求头验证逻辑：Cron自动触发的请求会携带X-Appengine-Cron: true的请求头，如果你在.NET API里做了仅允许带该头的请求通过的验证，手动"Run Now"的请求是没有这个头的，会被拦截。可以暂时去掉验证测试，或者手动触发时模拟这个头（比如用curl测试）。
• 查看GAE日志排查请求状态：打开GCP控制台的Cloud Logging，筛选你的GAE服务日志，搜索请求路径或"Run Now"相关记录，看请求是否真的到达了API，有没有返回403、500这类错误码。
• 验证Pub/Sub订阅与权限：确认Cron任务推送到了正确的Pub/Sub主题，订阅的推送端点指向你的.NET API，且订阅没有设置过滤规则导致消息被丢弃。另外检查GAE的服务账号是否拥有pubsub.publisher的IAM权限，没有权限的话消息根本发不出去。
• 直接测试API端点可用性：用Postman或curl直接调用你的API端点，传递和Cron触发相同的请求体（可以从日志里复制Cron触发的请求内容），看能不能正常执行任务，排除API本身的逻辑问题。

内容的提问来源于stack exchange，提问作者nwpie