Add-on Performance Expectations
Last updated 29 March 2018
Stability
Reliable and transparent operation is key to the success of any cloud service, including those powering Heroku add-ons. That said, any service will occasionally experience operational issues that affect customers. Acting and communicating appropriately around such events is critical to emerging with the customer’s trust and patronage intact.
Status page
Maintaining a service status page or blog is a simple way to inform users of any operational issues that could affect their usage. Having an always-up-to-date status provides a great starting point for any customer experience a problem, and can alleviate unnecessary load on your team in situations where all hands are required to fix a problem.
Scheduled maintenance
Always provide advance notice on any scheduled maintenance that will affect the operation of your service. In general, 24 hours is the least notice you should give your customers. You should both post the maintenance notice on your status page, and also notify users by email.
Interruptions and downtime
Unexpected downtime happens. When it does, it’s critical that you:
- Acknowledge the problem as soon as you know of it. Use the status page and email notifications.
- Restore service as quickly as possible, and notify using the same channels.
- Provide a post-mortem analysis explaining what went wrong, and what is being done to prevent a similar outage in the future.
Latency
Heroku is available in multiple geographic regions. As an add-on partner, your service may need to work under low-latency conditions, in which case it should be available in the same region as the app provisioning it. Read the Add-on Partner API overview to better understand what is expected of your service.
Latency considerations
Low-latency connections are critical for cloud services built to be consumed in realtime. These include:
- Databases such MySQL, CouchDB, or Casandra
- Cache stores such as Memcache
- Search services such as Websolr or Cloudquery
On the other hand, many services can tolerate an extra few hundred milliseconds of latency. Usually these are asynchronous services. For example:
- Email sending services such as Sendgrid and Authsmtp
- Outbound message services such as Messagepub or Chatterous
- Monitoring services like New Relic, Exceptional, or Airbrake
- DNS management services such as Zerigo DNS
Provisioning with latency
If your add-on service requires low latency then you should provision resources for Heroku apps within the same region as specified in the provision request region attribute.
If your add-on is latency sensitive and does not support that region, you should not provision the resource and instead return an error.
If normal internet latency is acceptable, you can run your service anywhere with a public hostname/IP.