5 ms·

Stripe Blog: Track Stripe's uptime

36 points by saikat 15y ago

latchkey 15y ago
Is it just me, or is this really confusing? Which services are responsible for taking payments? If the website goes down, does that affect taking payments? Isn't stripe.js part of the API? If the API goes down, doesn't that affect stripe.js? Also, what is up with all of that downtime? I think I'd expect my payment provider to have better uptime. Makes me wonder how quality the backend really is. If I was using stripe and my site couldn't accept payments for X minutes during a really important time (which seems to have happened 5 times in the last couple months), I'd be really pissed. Also, from a UX experience, getting my mouse pointer to line up over a 4 pixel wide line is a pain in the ass. It looks pretty, but isn't really usable. Update: Why the downvote? At least respond to me.
- pestaa 15y ago
  All your questions are fair, but I guess this site is for users who already know the difference between stripe.js and the API. Also, your worries are rightful but pointless. The API provided 4 nines and stripe.js is close to 5 nines in the last three months. There were no 10+ minutes downtimes in either (still not counting the website.) I think that is impressive uptime.
  - latchkey 15y ago
    I understand the difference between the two. The point I had is that stripe.js depends on the api. I don't understand why there is a separation in the status output. If the api is down, stripe.js is also down, you can see the reference to the api in the .js file. The way that my business works is that we take a large number of orders in a short amount of time and then it tapers off. If my site was down because their api is down for 4 minutes (and I don't know when it is going to come back up), that would really affect my sales. If you are at a cash register and pull out your credit card and the swiper doesn't work, chances are you can just hand the person cash. The internet doesn't work that way. 4 9's for a payment processor really isn't good enough. Also, that stat is just across 90 days, not 365. I really like Stripe and what they are trying to do. Now that I can visually see it, I just worry about their uptime performance. Update: Some one just sent me email calling me an asshole, which seems rather undeserving. This is their ip address pool-173-49-2-60.phlapa.fios.verizon.net.
    - dangrossman 15y ago
      > 4 9's for a payment processor really isn't good enough If 99.99% isn't good enough for you, then you should just store the payment data yourself so that you can re-send it if your gateway is unavailable during those critical 4 minutes. Payment processors of all sizes experience downtime. Authorizenet was down for almost a day last year despite having redundancy in every layer of their operations -- up to having an entire hot standby data center to fail over to. None of them lost all their customers and went out of business, so 4 9's IS good enough.
      - latchkey 15y ago
        They haven't lost customers because there is nowhere else to go.
  - 6ren 15y ago
    No. The site is a selling document, to potential developer-users. It sells the uptime and the honesty/integrity/trustworthiness of stripe. It should also be selling the simplicity, transparent communication and ease-of-use of stripe.
- citricsquid 15y ago
  Something that I think would also be nice would be if the dates were most recent on the left and oldest on the right. English is read left to right, so left should be the most relevant when displaying data and right being the least relevant, where most relevant = today and least relevant = 90 days. To me closest to where I start reading = closest to the current time.
  - boucher 15y ago
    We did have it going the other direction at first, but it didn't feel right.
    - carbocation 15y ago
      Almost all time-series data is represented with old data on the left, new data on the right. (Stock charts, etc.) The way you have https://status.stripe.com/ https://status.stripe.com/ set up makes sense to me.
- pc 15y ago
  Thanks for the honest feedback. Also, what is up with all of that downtime? I think I'd expect my payment provider to have better uptime. Makes me wonder how quality the backend really is. While all downtime is bad, we think 99.99% is decent. The best service providers -- including the services that might power your site -- tend to have guarantees in this range. Amazon EC2 and Google App Engine both have SLAs for 99.95% uptime. More generally, this is part of the point: other payments companies don't tend to talk about their availability at all. We think that this is harmful. What should count as acceptable uptime performance is a fair question. As a first step, we think we should all make our uptime public. Is it just me, or is this really confusing? Which services are responsible for taking payments? If the website goes down, does that affect taking payments? Isn't stripe.js part of the API? If the API goes down, doesn't that affect stripe.js? No, the Stripe site going down won't impact your ability to accept payments at all. stripe.js is optional, and so we've exposed its uptime separately too. Again, other services like Amazon and Google break out their availability on a per-service basis, and I think this makes a lot of sense.
  - latchkey 15y ago
    I don't see a SLA for Stripe on the ToS page, why not? GAE has actually had 100% uptime for the last year. http://googleappengine.blogspot.com/2012/01/happy-birthday-high-replication.html http://googleappengine.blogspot.com/2012/01/happy-birthday-h...
    - pc 15y ago
      That blog post refers to their high-replication datastore, not GAE as a whole.
    - moe 15y ago
      I don't see a SLA for Stripe on the ToS page, why not? Blanket SLAs are not normally worth the paper they're written on. Look up the breach-compensation for your favorite TOS-SLA sometime. Publishing the uptime history is a much more honest approach. Kudos to stripe for doing just that.
      - 15y ago
xxcode 15y ago
Why is this important? Why are you telling this to people? Why is this news that a Hacker should know. I might not get it, but IMHO if its not something of general interest, it shouldn't be on HN (even though the company might be PG's portfolio).
- learc83 15y ago
  Many people on HN are using Stripe to handle payment processing for their startups/projects. How can you argue this information isn't relevant?
  - saurik 15y ago
    Oh come now: the shear number of stories regarding Stripe that hit HN (and often hit it pretty hard, although this one did falter) is staggering. There are tons of services and technologies that "many people on HN are using" that don't get this kind of play; on the contrary, I've seen complaints before regarding "HN is not a change-log for ______".

36 points by saikat 15y ago

Is it just me, or is this really confusing? Which services are responsible for taking payments? If the website goes down, does that affect taking payments? Isn't stripe.js part of the API? If the API goes down, doesn't that affect stripe.js? Also, what is up with all of that downtime? I think I'd expect my payment provider to have better uptime. Makes me wonder how quality the backend really is. If I was using stripe and my site couldn't accept payments for X minutes during a really important time (which seems to have happened 5 times in the last couple months), I'd be really pissed. Also, from a UX experience, getting my mouse pointer to line up over a 4 pixel wide line is a pain in the ass. It looks pretty, but isn't really usable. Update: Why the downvote? At least respond to me.

pestaa 15y ago
All your questions are fair, but I guess this site is for users who already know the difference between stripe.js and the API. Also, your worries are rightful but pointless. The API provided 4 nines and stripe.js is close to 5 nines in the last three months. There were no 10+ minutes downtimes in either (still not counting the website.) I think that is impressive uptime.
- latchkey 15y ago
  I understand the difference between the two. The point I had is that stripe.js depends on the api. I don't understand why there is a separation in the status output. If the api is down, stripe.js is also down, you can see the reference to the api in the .js file. The way that my business works is that we take a large number of orders in a short amount of time and then it tapers off. If my site was down because their api is down for 4 minutes (and I don't know when it is going to come back up), that would really affect my sales. If you are at a cash register and pull out your credit card and the swiper doesn't work, chances are you can just hand the person cash. The internet doesn't work that way. 4 9's for a payment processor really isn't good enough. Also, that stat is just across 90 days, not 365. I really like Stripe and what they are trying to do. Now that I can visually see it, I just worry about their uptime performance. Update: Some one just sent me email calling me an asshole, which seems rather undeserving. This is their ip address pool-173-49-2-60.phlapa.fios.verizon.net.
  - dangrossman 15y ago
    > 4 9's for a payment processor really isn't good enough If 99.99% isn't good enough for you, then you should just store the payment data yourself so that you can re-send it if your gateway is unavailable during those critical 4 minutes. Payment processors of all sizes experience downtime. Authorizenet was down for almost a day last year despite having redundancy in every layer of their operations -- up to having an entire hot standby data center to fail over to. None of them lost all their customers and went out of business, so 4 9's IS good enough.
    - latchkey 15y ago
      They haven't lost customers because there is nowhere else to go.
- 6ren 15y ago
  No. The site is a selling document, to potential developer-users. It sells the uptime and the honesty/integrity/trustworthiness of stripe. It should also be selling the simplicity, transparent communication and ease-of-use of stripe.
citricsquid 15y ago
Something that I think would also be nice would be if the dates were most recent on the left and oldest on the right. English is read left to right, so left should be the most relevant when displaying data and right being the least relevant, where most relevant = today and least relevant = 90 days. To me closest to where I start reading = closest to the current time.
- boucher 15y ago
  We did have it going the other direction at first, but it didn't feel right.
  - carbocation 15y ago
    Almost all time-series data is represented with old data on the left, new data on the right. (Stock charts, etc.) The way you have https://status.stripe.com/ https://status.stripe.com/ set up makes sense to me.
pc 15y ago
Thanks for the honest feedback. Also, what is up with all of that downtime? I think I'd expect my payment provider to have better uptime. Makes me wonder how quality the backend really is. While all downtime is bad, we think 99.99% is decent. The best service providers -- including the services that might power your site -- tend to have guarantees in this range. Amazon EC2 and Google App Engine both have SLAs for 99.95% uptime. More generally, this is part of the point: other payments companies don't tend to talk about their availability at all. We think that this is harmful. What should count as acceptable uptime performance is a fair question. As a first step, we think we should all make our uptime public. Is it just me, or is this really confusing? Which services are responsible for taking payments? If the website goes down, does that affect taking payments? Isn't stripe.js part of the API? If the API goes down, doesn't that affect stripe.js? No, the Stripe site going down won't impact your ability to accept payments at all. stripe.js is optional, and so we've exposed its uptime separately too. Again, other services like Amazon and Google break out their availability on a per-service basis, and I think this makes a lot of sense.
- latchkey 15y ago
  I don't see a SLA for Stripe on the ToS page, why not? GAE has actually had 100% uptime for the last year. http://googleappengine.blogspot.com/2012/01/happy-birthday-high-replication.html http://googleappengine.blogspot.com/2012/01/happy-birthday-h...
  - pc 15y ago
    That blog post refers to their high-replication datastore, not GAE as a whole.
  - moe 15y ago
    I don't see a SLA for Stripe on the ToS page, why not? Blanket SLAs are not normally worth the paper they're written on. Look up the breach-compensation for your favorite TOS-SLA sometime. Publishing the uptime history is a much more honest approach. Kudos to stripe for doing just that.
    - 15y ago

xxcode 15y ago

Why is this important? Why are you telling this to people? Why is this news that a Hacker should know. I might not get it, but IMHO if its not something of general interest, it shouldn't be on HN (even though the company might be PG's portfolio).

learc83 15y ago
Many people on HN are using Stripe to handle payment processing for their startups/projects. How can you argue this information isn't relevant?
- saurik 15y ago
  Oh come now: the shear number of stories regarding Stripe that hit HN (and often hit it pretty hard, although this one did falter) is staggering. There are tons of services and technologies that "many people on HN are using" that don't get this kind of play; on the contrary, I've seen complaints before regarding "HN is not a change-log for ______".