Skip to content
Uptime Scheduler

Troubleshooting

Resource not appearing in the dashboard

The resource was just tagged — wait up to 60 seconds. Tag events flow through CloudTrail → EventBridge → Lambda. There is a small propagation delay.

Check the tag key is exactly uptime:schedule (colon, lowercase). A common mistake is using uptime-schedule or Uptime:Schedule.

Check CloudTrail is enabled in the region where the resource lives. CloudTrail management events must be enabled for the TagEventProcessor to receive tag events. If you’re using an existing CloudTrail, ensure it covers the relevant region.

Check the Lambda logs in CloudWatch for TagEventProcessor. Look for error messages or skipping log lines that indicate why the resource was not processed.

Schedule not firing

Verify the schedule format. The time range must come before the day specification. 9-17 mon-fri is valid; mon-fri 9-17 is not. See Schedule Format reference for the full syntax.

Check the timezone. Schedules fire in the timezone configured for your account. If your schedule fires at an unexpected time, confirm the timezone in the dashboard settings.

Check EventBridge Scheduler rules in your AWS account. In the EventBridge console, navigate to Schedules and look for entries prefixed with uptime-. Verify that start and stop schedules exist for the resource.

Check the ActionProcessor Lambda logs in CloudWatch. Look for errors on the relevant processor (e.g. NATActionProcessor, EC2ActionProcessor).

NAT Gateway route not restoring after start

If private subnets lose internet access after a NAT Gateway is recreated:

  1. Check the NATActionProcessor CloudWatch logs for route restoration errors
  2. Verify the route table IDs saved in DynamoDB match the current route tables in your VPC (navigate to the DynamoDB table in your account and look for the Metadata attribute on the NAT record)
  3. If route tables were modified while the gateway was stopped, you may need to manually update the routes

Resource is stuck in a transitional state

If a resource shows pending, stopping, or starting in the dashboard for an extended period:

  1. Check the actual state in the AWS Console — the dashboard may be slightly behind
  2. Check the ActionProcessor Lambda logs for timeout or API errors
  3. For NAT Gateways, check the VPC console for the gateway state

CloudFormation deployment fails

CAPABILITY_NAMED_IAM not specified. The stack creates named IAM roles. You must pass --capabilities CAPABILITY_NAMED_IAM when deploying via CLI, or acknowledge the IAM capability in the Console.

Insufficient permissions. Ensure the deploying principal has the permissions listed in IAM Permissions.

Stack already exists. If a previous failed deployment left a stack in ROLLBACK_COMPLETE state, delete it before redeploying.

Dashboard shows “No accounts connected”

Ensure the CloudFormation stack deployed successfully and that the heartbeat Lambda has sent at least one event. Check CloudWatch for the HeartbeatProcessor Lambda — it runs every 6 hours.

Checking Lambda logs

All Lambda functions write structured logs to CloudWatch Logs. Log groups follow the pattern:

/aws/lambda/<StackName>-<FunctionName>

For example:

/aws/lambda/uptime-scheduler-TagEventProcessor
/aws/lambda/uptime-scheduler-NATActionProcessor
/aws/lambda/uptime-scheduler-ScheduleManager

Use CloudWatch Log Insights to search across all functions:

fields @timestamp, @message
| filter @logStream like /TagEventProcessor/
| sort @timestamp desc
| limit 50