Hosting and monitoring
Last updated
Was this helpful?
Last updated
Was this helpful?
Digital is in charge of maintain/help support/be technical advisors on nearly all of the mobile apps obtained by the City. They can be found on these.
We use for describing our infrastructure. See the repo.
Do not make one-off changes in the UI or with the command line. Everything should be updated through Terraform so we have transparency about what we’re running and why.
Terraform changes should be made through .
Acquia externally hosts our main website, boston.gov in their cloud instance.
Heroku is appropriate for very one-off apps (such as the 311 crowdsource app) where we don’t mind not being on a boston.gov URL or waiting for the dyno to spin up after inactivity.
We only want to use free tier dynos going forward.
We need to get off all paid Heroku services, migrating to AWS/S3 as appropriate. Staging apps, however, should generally deploy to AWS to match production-like environments.
We should never be surprised by an outage. CloudWatch and/or Updown.io should be monitoring our apps and the services they depend on.
If an alarm goes off regularly, either its root cause should be fixed or the alarm should be adjusted or removed.
We have a handful of CloudWatch alarms to monitor our instances, VPN, and services.
Exceptions we cannot eliminate should be silenced on the Rollbar side or prevented from throwing in the first place. If necessary, they should be converted to logs that can be monitored.
Yes, parking tickets goes down every night and it’s annoying.
These alarms are sent to the digital-dev@boston.gov email address and posted in the #digital_monitoring Slack channel via a custom .
We use to track server-side and client-side exceptions.
We use for blackbox monitoring of our sites’ availability.