# Postman v2 SLOs ### 1. What are the Postman SLOs? * It is important to distinguish between the Service Level Objectives (SLOs) for Postman and the overall systems SLOs. Postman, as an integrated component within the larger system, has its own specific SLOs. Postman-specific SLOs focus on the performance, reliability, and efficiency of the Postman product itself. In other words, the Postman team is directly responsible for maintaining and monitoring these product-specific SLOs. * In contrast, the overall system SLOs encompass the end-to-end performance of the entire integrated system, including Postman and all downstream components such as Tier 1 SMS Aggregators and Telcos. * The Postman product contributes to the overall system performance. Therefore, our primary responsibilities and accountabilities lie with meeting and upholding the Postman-specific SLOs. The other individual players are held to their own SLOs and SLAs that are separate from Postman's SLOs with you. * We actively manage and optimise Postman to meet these objectives, thereby ensuring our component's optimal contribution to the broader system performance. ### **2. What is Postman v2’s system uptime?** * Postman aims to have an uptime of >99.5%. We have internal services to monitor Postman uptime 24/7. These services send alerts if the product is down to the engineer-on-call, so that we can respond as soon as possible. * If you are unable to access Postman services and would like to check if it is due to an unplanned downtime, check our status page [here](https://www.sms.gov.sg/status). ### 3. **Any maintenance downtime for Postman v2?** * No, we will inform all users if there is going to be a scheduled downtime. ### 4. Subscribe to status updates: * If you are unable to access Postman services and would like to check if it is due to an unplanned downtime, check our status page [here](https://status.postman.gov.sg/). You can also subscribe yourself to email notifications. * Typically, we inform users of downtime only if resolution is expected to take longer than a day, or if your campaign is directly affected. ### **5. How long can I expect a reply for my queries?** * Please ensure your requests are submitted via this [form](https://form.gov.sg/657025a2d2bd350012c82eb0), rather than through emailing the team, as we are unable to respond promptly to individual emails. * Please note the following SLAs for response times. Do note that marking non-urgent requests as urgent will not result in a response immediately - the BTN team will filter requests based on the following table below.

Priority Level	Examples (non-exhaustive)	You can expect a first response...
Urgent	Product incident causing widespread delays, and not due to agency's own lapses in campaign set-ups/processes. Confidentiality or privacy breaches. User data losses.	Within 3 hours.
High	Agency campaigns are affected due to errors related to Postman.	Within 1 working day.
Medium	General inquiries relating to campaigns, billing, product, etc.	Within 3 working days.
Low	Feature requests, feedback/suggestions, answers that can already be found in guide.	Within 5 working days.

### 6. **What are Postman's rate limits?** * For more information on rate limits, please click [here](https://postman-v2.guides.gov.sg/general-notes-for-api-users/rate-limits). ### 7. Where and when can I expect to be informed about updates to Postman? * Whenever we make an update to the product, it will be listed on our [updates page](https://postman-v2.guides.gov.sg/postman-v2-api-docs/postman-guide-latest-updates). * We will also communicate this on our BTN Microsoft Teams channel called "WOG Channel for BTN". If you are not in this channel, please let us know by submitting this [form](https://form.gov.sg/657025a2d2bd350012c82eb0). Note that only users with emails ending in ".gov.sg" can be added to the channel. Vendors cannot be added to the channel. * Where a product update is significant and will affect your workflows, we will communicate this through email blasts to all users of the Postman v2 test and production environments. * We seek your understanding that as the product is still developing and the situation remains dynamic, changes may be made along the way, and may affect your current system set-ups. As far as possible, we will try our best to communicate this to you with significant heads-up for you to make the necessary preparations. * We apologise in advance for cases where we inform of changes in a short span of time. ### 8. What is the expected deliverability standards i can expect for my campaign? If you're 1) sending to local numbers, 2) Using only GSM characters, 3) less than 6 message segments, you can expect: **Overall Systems** **SLOs**

Metrics Description

Terminal status (%)

Metrics	Description
Terminal status (%)	Within 48 hours 95% of all messages will reach terminal status (`success` or `failure)` After 80 hours All messages will reach terminal status (`success` or `failure`)
Time taken for your message to reach your recipient	Single Send 90% of messages will reach terminal status in under 2 minute Batch Send For batches of up to 1 Million messages, 90% of messages will reach terminal status under 24 hours

Within 48 hours

95% of all messages will reach terminal status (success or failure)

After 80 hours

All messages will reach terminal status (success or failure)

Time taken for your message to reach your recipient Single Send
90% of messages will reach terminal status in under 2 minute

Batch Send
For batches of up to 1 Million messages, 90% of messages will reach terminal status under 24 hours

**Postman System SLOs**

Metrics	Description
Availability	Single Send 99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful) Retrieve Single Send Messages 99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful) Batch Send 99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful) Retrieve Batch Send Messages 99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful)
Latency	Single Send 99.9% of requests per month, excluding network latency, have a response under 500ms Retrieve Single Send Messages 99.9% of requests per month, excluding network latency, have a response under 300ms Batch Send 95% of requests per month, excluding network latency, have a response under 3s 99.9% of requests per month, excluding network latency, have a response under 15s Retrieve Batch Send Messages 95% of requests per month, excluding network latency, have a response under 500ms 99.9% of requests per month, excluding network latency, have a response under 5s

Metrics

Description

Availability

Single Send
99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful)

Retrieve Single Send Messages
99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful)

Batch Send
99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful)

Retrieve Batch Send Messages
99.9% of requests per month have a successful response (Any HTTP response other than 500-599 is considered successful)

Latency

Single Send
99.9% of requests per month, excluding network latency, have a response under 500ms

Retrieve Single Send Messages
99.9% of requests per month, excluding network latency, have a response under 300ms

Batch Send
95% of requests per month, excluding network latency, have a response under 3s
99.9% of requests per month, excluding network latency, have a response under 15s

Retrieve Batch Send Messages
95% of requests per month, excluding network latency, have a response under 500ms
99.9% of requests per month, excluding network latency, have a response under 5s

**Sending to Foreign Numbers** Messages sent to foreign numbers and overseas recipients will be delivered on a best-effort basis only. Additionally, you may experience increased failure rates for messages sent to Chinese mobile numbers (+86) due to updated sending requirements from Chinese operators. If you are sending time-critical messages (e.g., OTP messages), kindly consider alternatives like email. ### 9. Please see the table below for guidelines on incident handling: | Severity level | What it means | Examples | Resolution time | | -------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | 1 | A critical incident with very high impact |

A user-facing service like Postman is down for all users.
Confidentiality or privacy is breached.
User data loss.

A user-facing service like Postman is unavailable for a subset of users.
Core functionality (e.g. sending messages, creating campaigns) is significantly impacted.

A minor inconvenience to users as workarounds are already available.
Usable performance degration.

| Within THREE (3) working days. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://postman-v2.guides.gov.sg/postman-v2-api-docs/about-postman-v2/postman-v2-slos.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.