Summary

We are committed to resolving any issue you encounter as swiftly as possible. To facilitate this process, please adhere to the following three guidelines: 

1. Always answer "What happened and when?". Our support teams will always require the following information: (a) the action you were attempting, (b) the issue you encountered, (c) the time the issue began, and (d) whether the issue is still occurring. This information will assist us in accurately triaging the situation, assessing its severity, narrowing the scope of our investigation, and minimizing the time spent on triage.
2. Include specific calls to and responses from the Paxos API. When encountering an issue, it is essential for us to know which service you were utilizing. If you are creating or updating an object, please provide the request body you used at the time of the issue, along with the corresponding response body. Please note that we do not log the API request and response bodies.
3. Include screenshots for issues with UI. Submitting a screenshot of an error message or JSON payload instead of including it as text in the ticket description forces our support teams to read and manually transcribe the payload, rather than allowing them to copy and paste. This process is time-consuming, prone to errors, and can lead to delays.

Examples

Example 1: Production Outage

Bad

Subject: URGENT ISSUE

Description: Our application is down please advise

Good

Subject: Production appears down

Description: We began observing 503 errors from all services beginning at 13:02 UTC. The issue is ongoing.

Comments

The first example lacks specifics about what happened or when it occurred, and an application's downtime could result from an issue unrelated to Paxos. As a result, our support teams would need to start by investigating and clarifying the situation, potentially delaying resolution. However, if all services return 503 errors, it would clearly indicate a problem on Paxos’s side, allowing us to skip the triage phase. Knowing that the issue is ongoing confirms it as an active S1 incident, and the timestamp of when it began helps us identify any changes that may have caused it.

Example 2: Troubleshooting Request

Bad

Subject: Identity service not working

Description: Please fix

Good

Subject: Receiving 400 response from identity service

Description: When I post the following payload to the identity service, I receive a 400 error. Why?

{
  “person_details": {
  “first_name": "John"
  “last_name": "Smith",
  “date_of_birth": "1900-07-31",
  “govt_id": "XXX-XX-XXXX",
  “govt_id_type": "SSN",
  “address": {
  “country": "USA",
  “address1": "4677 Main St",
  “city": "Atlanta",
  “province": "GA",
  “zip_code": "30301"
  },
  “nationality": "USA",
  “verifier_type": "PASSTHROUGH",
  “passthrough_verifier_type": "JUMIO",
  “passthrough_verified_at": "2021-07-21T22:26:50.916442Z"
 }
}

Comments

The second ticket provides the payload, which is essential for identifying the cause of the error. In this case, the issue is due to a missing comma on line 3, rendering the JSON invalid.