Security
Sample security practices for Tern check credentials, account access and incident reporting.
Sample text. This page is a starting point, not legal advice. Replace it with your own terms and have them checked.
This sample page is dated September 1, 2026. It describes intended practices for the fictional Tern service, rather than verified controls for a deployed product. The demonstration app and checkout links are placeholders. Replace this page with evidence-based statements before operating a real monitoring service.
Account access
A live Tern account should give each team member a separate login so access can be removed without changing everyone else’s credentials. Business includes single sign-on. Account owners should review members when roles change and remove people who no longer need access.
API tokens should have limited permissions and be rotated after suspected exposure. Do not put tokens in public repositories, screenshots or support messages. Signed webhooks let your receiver verify the sender and reject altered messages; the receiver should also check the timestamp to reduce replay risk.
Check credentials and storage
Monitoring sometimes requires an authentication header or a private heartbeat URL. Treat both as secrets. Use a dedicated credential that can read only what the check needs, and avoid a credential that can alter production data. A heartbeat URL should not appear on a public status page.
Account records, check history and incident data are intended to be stored in Frankfurt in the EU. Workers in six regions need access to the settings required to run each check. A real implementation should protect traffic in transit, encrypt stored secrets, restrict staff access and record administrative access. These controls need verification before they can be presented as operational facts.
Public pages and alert channels
Check results and incident updates can contain details that should stay within your team. Review the services and text you choose to publish. Public pages should describe customer impact without exposing private endpoint addresses, credentials or personal contact information.
Email, SMS, phone calls and team-chat webhooks send incident information outside the app. Configure only destinations your team controls, and keep sensitive details out of alert text. Before using a route overnight, send a test and confirm the current on-call person receives it.
Reporting a problem
Send suspected vulnerabilities to hello@tern.example.com with the affected page or endpoint, the steps needed to reproduce the issue and the impact you observed. Use a test account and stop if you encounter another person’s data. Do not attach secrets or personal information.
We aim to acknowledge reports within one working day. A real service should arrange a private channel for sensitive evidence and keep the reporter informed while investigating. This sample makes no certification, audit or guaranteed response-time claim. It also does not grant permission to disrupt the service or access accounts without authorization.