Postman v2 SLOs
SLOs are Service Level Objectives, which provide you with insight on the goals and objectives that the Postman product holds itself to.
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.
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. 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?
We will get back to you on your form submissions within 5 working days.
Please ensure your requests are submitted via this form, rather than through emailing the team, as we are unable to respond as promptly to individual emails.
6. What are Postman's rate limits?
For more information on rate limits, please click here.
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.
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. 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
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
Postman System SLOs
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
8. Please see the table below for guidelines on incident handling:
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.
Within THREE (3) hours.
2
An incident with low impact
A user-facing service like Postman is unavailable for a subset of users.
Core functionality (e.g. sending messages, creating campaigns) is significantly impacted.
Within TWENTY FOUR (24) hours.
3
A small bug or issue affecting a single user
A minor inconvenience to users as workarounds are already available.
Usable performance degration.
Within THREE (3) working days.
Last updated