You built a custom Alexa Skill or Google Action months ago. It worked for a while. Now when you trigger it, you get an error response or no response at all. You have not changed anything on your side. The skill stopped working on its own. This is a common pattern with custom voice integrations because the platforms underneath them change without notice.
What custom skills depend on
A custom Alexa Skill or Google Action is a small program that runs in the cloud. It depends on:
- The voice ecosystem’s APIs and SDKs
- A hosting environment (AWS Lambda, Google Cloud Functions, or self-hosted)
- OAuth tokens for any external services it calls
- Permissions granted by your account
Any of these can break without warning.
Check the platform changelog first
Amazon’s Alexa Skills Kit has periodic updates that deprecate older SDK versions. Google’s Actions on Google has had similar deprecations. If your skill stopped working at a specific date, check the Amazon Developer Console or the Actions Console for any deprecation notices.
Common deprecations:
- SDK version no longer supported
- Permission model changed
- Endpoint URL deprecated
- Authentication flow changed
Check your hosting
If you are hosting on AWS Lambda or Google Cloud Functions, check the function’s status. Cloud providers occasionally update their runtime versions, deprecating older ones. Your function may have stopped running because its Node.js or Python runtime was retired.
To check:
- AWS Lambda: log into the AWS console, navigate to your function, check the runtime field. If it shows “deprecated runtime”, you need to upgrade.
- Google Cloud Functions: similar console check.
- Self-hosted: SSH to your server, check the application’s logs.
OAuth token rotation
If your skill calls an external service through OAuth, the token may have expired. Most services use short-lived access tokens with longer-lived refresh tokens. If your skill code only handled access tokens and assumed they would not expire, the skill fails when the token expires.
Fix: implement refresh token handling. The OAuth library for your runtime usually has support; you may not have configured it.
Permission changes
Both Alexa and Google have evolved their permission models. Permissions that were implicit when you built your skill may now require explicit user consent. If you have not re-published the skill since the change, the user-facing prompt may never appear and the skill may fail to access the data it needs.
Re-publish your skill (you do not need to make code changes, just trigger a publish) and the latest permission model takes effect.
Account linking breaks
If your skill requires account linking (the user signs into your service from inside Alexa or Google Home), the link can break when:
- The user changes their password on your service
- Your service’s OAuth endpoint URL changes
- The OAuth client credentials change
- The skill itself is updated and re-linking is required
The user-side fix: open the Alexa app or Google Home app, disable the skill, then re-enable it, completing the account link fresh.
SSL certificate issues
If your skill is hosted on a self-managed server, the SSL certificate must be valid. Many users use Let’s Encrypt with auto-renewal, but auto-renewal can fail (rate-limited, DNS issue, ACME challenge unable to reach the server).
Check the certificate’s expiry. Renew if needed. Test by visiting your endpoint URL in a browser; if it shows a certificate error, the voice ecosystem cannot reach it either.
Endpoint URL changes
If you moved your hosting (changed AWS regions, moved to a different cloud provider, changed domains), the skill’s endpoint URL in the developer console may still point to the old location. Update the endpoint in the console and republish.
Log everything
The most useful thing for custom skill maintenance is logging. Every skill invocation should log to CloudWatch (AWS), Cloud Logging (Google), or your own log file. When something breaks, you can see exactly where it failed.
If you did not set up logging when you built the skill, add it now. The next breakage will be much easier to diagnose.
Test invocation through the developer console
Both Amazon and Google have developer consoles that let you test your skill without using a real device. The console shows the full request and response. When a skill breaks, testing through the console isolates whether the issue is in the skill itself or in the device’s ability to invoke it.
The dependent service change
If your skill talks to a third-party API (weather, news, your home automation hub), the third-party API can change. APIs deprecate endpoints, change response formats, rate-limit your account.
Document the APIs your skill depends on. When the skill breaks, check each one’s status page and changelog.
Test after every platform update
Amazon’s Alexa Skills Kit and Google’s Actions on Google update on their own schedule, not yours. After major updates, take 10 minutes to test your custom skills. Breakages caught early are easier to fix than breakages discovered weeks later when you have lost context.
When to retire the skill
If your skill has been breaking repeatedly and you cannot keep up with platform changes, consider whether the use case still justifies the maintenance. Many custom voice integrations were built to fill gaps that have since been filled by official integrations (HomeKit’s improved third-party support, Matter, official Hue Skill features).
Replacing a custom skill with an official integration is often the lower-maintenance path long-term.
The dependency log every custom-skill operator wishes they kept
Custom Alexa Skills and Google Actions depend on external APIs that change without notice. The skill keeps working until one of its dependencies updates, then breaks abruptly. Keeping a small text file listing every API your skill calls, with version notes, makes regression diagnosis much faster.
When a skill fails, you can scan the dependency list, check each API’s recent changelog, and identify the breaker quickly. Without the list, you start from zero each time. For the broader picture of cross-ecosystem skill maintenance, see our cross-ecosystem voice guide.
The deprecation alert subscription
Amazon and Google both publish developer changelogs that include deprecation notices. Subscribing to the RSS feed or developer mailing list gives you advance warning before your custom skills break. Two weeks of warning is typically enough to refactor and redeploy without user-visible downtime. For the broader pattern of platform-side changes affecting users, see our Google sync failures guide.
